Quantcast

Re: How does --hwmix work?

classic Classic list List threaded Threaded
49 messages Options
123
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How does --hwmix work?

Ralf Mardorf
On Tue, 02 May 2017 21:59:48 +0200, David Kastrup wrote:
>I have an RME Hammerfall DSP, a card that I believe supports --hwmix on
>jackd.  How does this work?  Does this require special support by the
>application?  If so, which applications exist using it via Jack?

Hi,

I don't know what this option should do [1], maybe you are confusing
it with hwmon. IIUC HWMIX is a feature to use a sound card without a
sound server, but since jack is a sound server, this option might be
irrelevant. I might be mistaken ;).

However, if you want a hardware mixer, you don't need a jack option,
instead try running   hdspmixer   . I suspect hdspmixer doesn't work
with all RME cards.

Regards,
Ralf

[1]
[rocketmouse@archlinux ~]$ man jackd | grep hwmix -A3
[rocketmouse@archlinux ~]$ man jackd | grep hwmon -A3
       -H, --hwmon
              Enable hardware monitoring of capture ports.  This is a
method for obtaining "zero latency" mon‐ itoring  of  audio  input.
It requires support in hardware and from the underlying ALSA device
driver. --
              (M-Audio  Delta  series,  Terratec,  and  others) support
--hwmon.  In the future, some consumer cards may also be supported by
modifying their mixer settings.

              Without --hwmon, port monitoring requires JACK to read
              audio into system memory,  then  copy  it back  out  to
              the  hardware  again,  imposing  the  basic JACK system
              latency determined by the --period and --nperiods
              parameters.

--
"Access to all language versions of Wikipedia was blocked in Turkey on
29 April 2017." -
https://en.wikipedia.org/wiki/Government_censorship_of_Wikipedia#Turkey
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How does --hwmix work?

David Kastrup
Ralf Mardorf <[hidden email]> writes:

> On Tue, 02 May 2017 21:59:48 +0200, David Kastrup wrote:
>>I have an RME Hammerfall DSP, a card that I believe supports --hwmix on
>>jackd.  How does this work?  Does this require special support by the
>>application?  If so, which applications exist using it via Jack?
>
> Hi,
>
> I don't know what this option should do [1], maybe you are confusing
> it with hwmon. IIUC HWMIX is a feature to use a sound card without a
> sound server, but since jack is a sound server, this option might be
> irrelevant. I might be mistaken ;).
>
> However, if you want a hardware mixer, you don't need a jack option,
> instead try running   hdspmixer   . I suspect hdspmixer doesn't work
> with all RME cards.

hdspmixer works with the Hammerfall DSP but it writes all over the mixer
right on startup.  Not suitable for changing single settings: I am using
alsactl for that right now.

> [1]
> [rocketmouse@archlinux ~]$ man jackd | grep hwmix -A3
> [rocketmouse@archlinux ~]$ man jackd | grep hwmon -A3
>        -H, --hwmon
>               Enable hardware monitoring of capture ports.  This is a
> method for obtaining "zero latency" mon‐ itoring  of  audio  input.
> It requires support in hardware and from the underlying ALSA device
> driver. --
>               (M-Audio  Delta  series,  Terratec,  and  others) support
> --hwmon.  In the future, some consumer cards may also be supported by
> modifying their mixer settings.
>
>               Without --hwmon, port monitoring requires JACK to read
>               audio into system memory,  then  copy  it back  out  to
>               the  hardware  again,  imposing  the  basic JACK system
>               latency determined by the --period and --nperiods
>               parameters.

Sigh, you are right.  But the question remains:  What applications will
support this and what does it mean?  For example, the DSP Hammerfall has
about two dozen inputs and about two dozen outputs.  What does "hardware
monitoring of capture ports" mean then?  Where are they monitored to by
which application?

--
David Kastrup
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How does --hwmix work?

Chris Caudle
On Wed, May 3, 2017 1:05 am, David Kastrup wrote:
> Sigh, you are right.  But the question remains:  What applications will
> support this and what does it mean?

If you are recording something you presumably want or need to hear what
you are recording.  There are three ways to do this:

You connect what you are recording (microphone, keyboard, etc.) to a
hardware mixer, that mixer sends the audio to the computer audio interface
and also to the speakers.  You may need to also take output from the
computer audio interface and mix with what you are recording before
sending to the speakers (for example you are adding tracks to some already
recorded material and need to hear both the existing material and what you
are playing).

The second method is that what you are recording goes only to the computer
audio interface, the computer does any mixing required with pre-recorded
material, and the output from the computer audio device goes to the
speakers for  you to listen to.  The disadvantage is that the audio you
hear is delayed by two conversion paths (into the computer and out of the
computer) plus whatever time is taken by the software actually processing
the audio.

The third method is what is meant by hwmon, the audio you are recording
goes to the audio interface, but rather than being transferred into the
computer and requiring the software to process and send back to the
output, the audio interface hardware sends the input signal directly to
the output, optionally mixing with audio being sent from the computer
software at the same time.  That can be done at the analog stage or the
digital stage.  For example, I have an interface where the analog output
can be directly from the DAC (converting the digital audio sent from the
computer), or can be directly from the input circuitry, or  you can mix
between, all controlled with a knob and implemented with analog circuitry.
Your HDSP device can do something similar, but done after the analog to
digital conversion, so that you can control the level and mix with
software instead of using a knob on the interface hardware.

Where this makes a difference is when you are using a recording
application such as Ardour, if you configure Ardour so that it uses
software monitoring, Ardour will mix the incoming audio with the existing
material and send back out to the audio output.  If you configure for
hardware monitoring, then Ardour will only play back the existing
material, and the hardware is responsible for mixing the incoming audio
material with the output of pre-existing material so you can hear both.
Note that both method 1 and method 3 would be classifired as hardware
monitoring, it only differs in whether you have an external mixer handling
the task or you computer audio interface can handle the task.

--
Chris Caudle


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How does --hwmix work?

David Kastrup
"Chris Caudle" <[hidden email]> writes:

> On Wed, May 3, 2017 1:05 am, David Kastrup wrote:
>> Sigh, you are right.  But the question remains:  What applications will
>> support this and what does it mean?

[Large treatise regarding hardware monitoring elided]

> Where this makes a difference is when you are using a recording
> application such as Ardour, if you configure Ardour so that it uses
> software monitoring, Ardour will mix the incoming audio with the
> existing material and send back out to the audio output.  If you
> configure for hardware monitoring, then Ardour will only play back the
> existing material, and the hardware is responsible for mixing the
> incoming audio material with the output of pre-existing material so
> you can hear both.  Note that both method 1 and method 3 would be
> classifired as hardware monitoring, it only differs in whether you
> have an external mixer handling the task or you computer audio
> interface can handle the task.

Uh, the question was not what hardware monitoring is.  The question was
what the --hwmon option to Jackd does and which applications support it.

"the hardware is responsible for mixing the incoming audio material" is
nothing that Jackd would be involved with since Jackd isn't hardware.

So what does this option do?  The manual page reads (as you cited):

        -H, --hwmon
                Enable hardware monitoring of capture ports.  This is a
                method for obtaining "zero latency" monitoring of audio
                input.  It  requires support  in hardware and  from the
                underlying ALSA device driver.

                When enabled, requests to monitor capture ports will be
                satisfied  by creating  a  direct  signal path  between
                audio interface  input and  output connectors,  with no
                processing by  the host  computer at all.   This offers
                the lowest possible latency for the monitored signal.

                Presently (March 2003), only  the RME Hammerfall series
                and cards  based on the ICE1712  chipset (M-Audio Delta
                series, Terratec, and others)  support --hwmon.  In the
                future, some  consumer cards  may also be  supported by
                modifying their mixer settings.

                Without --hwmon, port monitoring  requires JACK to read
                audio into system memory, then  copy it back out to the
                hardware again, imposing the  basic JACK system latency
                determined by the --period and --nperiods parameters.

But what does this mean when I have 26 capture ports and 18 output
ports?  What kind of applications request to "monitor capture ports",
and what ports will get a direct signal path between them?

When I use Ardour, I have settings for "Ardour is responsible for
monitoring" and "Hardware is responsible for monitoring".  For which of
the two settings would the --hwmon option to Jackd be even relevant?

Wait.  Now I see _three_ settings.

Record monitoring handled by:
"via Audio Driver"
"ardour"
"audio hardware"

[Testing out several things]

Ok, the "via Audio Driver" option is not there when Jackd runs on my
default laptop hardware (AC97) but it is there when it runs on the RME
Hammerfall DSP.  But independently of whether or not I specify --hwmon.
So does this option actually make a difference to Jackd?

Either way, what is the effect?  Does Ardour take the gain totals
(disregarding all other plugin effects) from its jackd-controlled
hardware inputs to its record-enabled tracks and from its record-enabled
tracks to its jackd-controlled hardware outputs, convert them to mixer
settings and hand them over?

That would be what I consider "best case".  It is also something about
which I can find nothing whatsoever in the Jack API documentation (as
seen on its web site).  So it's hard to guess at the actual capabilities
being exercised here.

If it accesses the mixer like that, it's actually a bit more than just
monitoring.  Who does the latency accounting in this case?  The
Hammerfall docs state 4 samples delay at 48kHz and its ilk and 8 samples
delay at 96kHz and its ilk for the digital signal paths.  For the analog
signals, A/D has 31 samples delay due to oversampling/filtering and D/A
has 30 samples delay.

So basically Ardour's menu "Editor/Audio/Monitoring/Record monitoring
handled by:" gains an additional option "via Audio Driver" on certain
hardware, independently of whether jackd has been started with --hwmon
or not.

This magic third option is not mentioned in the Ardour manual
<http://manual.ardour.org/preferences-and-session-properties/preferences-dialog/audio/>:

    Record monitoring handled by: determines whether Ardour provides
    monitoring of incoming audio or whether monitoring is provided by
    hardware. See
    Monitoring(http://manual.ardour.org/recording/monitoring/) for more
    information.

And "Monitoring" is actually less rather than more information:

    When recording, it is important that performers hear themselves, and
    to hear any pre-recorded tracks they are performing with. Audio
    recorders typically let you monitor (i.e. listen to) the input
    signal of all tracks that are armed for recording, and playing back
    the unarmed tracks.


So does --hwmon make an actual difference (I should likely mention that
I used Jack2 for this experiment)?  And what actually happens?  And is
there any documentation about any of this and the involved APIs
anywhere?  And if this requires special Jackd support (as the manual
page suggests) rather than being able to work with more generic
ALSA-accessible mixers (like, say, the AC97 mixer), where would one find
out about just which cards are supported in 2017?  The manual page
states "Presently (March 2003)" which is not particularly up to date.

--
David Kastrup
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How does --hwmix work?

Ralf Mardorf
On Wed, 03 May 2017 18:07:31 +0200, David Kastrup wrote:
>Without --hwmon, port monitoring  requires JACK to read
> audio into system memory, then  copy it back out to the
> hardware again, imposing the  basic JACK system latency
> determined by the --period and --nperiods parameters.

If you are using hdspmixer, then "Without --hwmon" routing the signal
could be done without latency, IOW you do _not_ need to use the
"--hwmon" option. FWIW "zero latency" doesn't mean 100% "zero
latency", it just means that it is "zero latency" for our perception
and even for the perception of an autistic savant. You at least get the
latency caused by the speed of light and delay by a few electronic
components.

There is no software that supports "--hwmon", but seemingly some audio
interfaces allow hardware monitoring, when using this option. If you
are using hdspmixer you don't need it and if you are using a mixing
console, you even don't need hdspmixer to do hardware monitoring.

Regards,
Ralf

--
"Access to all language versions of Wikipedia was blocked in Turkey on
29 April 2017." -
https://en.wikipedia.org/wiki/Government_censorship_of_Wikipedia#Turkey
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Jack-Devel] How does --hwmon work? (was: How does --hwmix work?)

David Kastrup
Ralf Mardorf <[hidden email]> writes:

> On Wed, 03 May 2017 18:07:31 +0200, David Kastrup wrote:
>>Without --hwmon, port monitoring  requires JACK to read
>> audio into system memory, then  copy it back out to the
>> hardware again, imposing the  basic JACK system latency
>> determined by the --period and --nperiods parameters.
>
> If you are using hdspmixer, then "Without --hwmon" routing the signal
> could be done without latency,

Can we focus on the question of what happens _with_ --hwmon to jackd
and/or the "via Audio Driver" monitoring option in Ardour?

I know what the mixer hardware can do in general and specifically when
using hdspmixer (or the equivalent amixer -d hw:DSP cset numid=5 ...).
But that's not relevant to Jack and wasn't my question.

> IOW you do _not_ need to use the "--hwmon" option. FWIW "zero latency"
> doesn't mean 100% "zero latency", it just means that it is "zero
> latency" for our perception and even for the perception of an autistic
> savant. You at least get the latency caused by the speed of light and
> delay by a few electronic components.

Sigh.  I even listed the latencies involved here already.  Since the
mixing is in the digital domain, you get buffering delays and the delays
for the down-/up-sampling filters of A/D-D/A conversion, roughly 2ms all
in all.

> There is no software that supports "--hwmon", but seemingly some audio
> interfaces allow hardware monitoring, when using this option.

That does not even make sense.  The audio interface needs to get passed
information by some software in order to do something specific.  It does
not have a button labelled "--hwmon" on its box.

> If you are using hdspmixer you don't need it

I was not talking about using hdspmixer.  The question was what effects
jackd --hwmon and/or the Ardour monitoring option "via Audio Driver"
(discovered after the initial question was already posed but very likely
related) have.

Also the question was where information about supported cards and the
used API to Jack were to be found since the manual page describing the
options represented the status as of 2003 AD.

> and if you are using a mixing console, you even don't need hdspmixer
> to do hardware monitoring.

And if I am using a tape drive, I don't even need a computer.  But let's
assume, for the sake of solving this question, that I am using a
computer, not a mixing console, an RME Hammerfall DSP (or some other
supported card, whatever it may be) and am not using hdspmixer in order
to set up a monitoring solution independent of Jack and/or Ardour.

--
David Kastrup
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How does --hwmon work?

David Kastrup
David Kastrup <[hidden email]> writes:

> Ralf Mardorf <[hidden email]> writes:

>> If you are using hdspmixer you don't need it
>
> I was not talking about using hdspmixer.

To expound slightly on that: hdspmixer is not integrated into Ardour,
and as opposed to its Windows/MacOSX software counterpart (Totalmix), it
does not offer Midi automation.

I am currently in the process of Frankensteining a Roland FR1b "virtual
accordion" with soft- and hardware Midi expanders, and the Roland only
has a single Midi connector that is either in- or output.  So when the
registration calls for the Roland to be silent, I have to access the
mixer programmatically.

Since I don't want the software to be tied to a particular soundcard, a
more generic interface that _does_ use hardware monitoring/mixing of
some kind internally when available would seem like the best fit.

But it's not clear to me where which stuff is being done and whether,
say, using jack_mix_box for the Roland sound control will magically buy
me "zero-latency" monitoring or not.

It really depends on what --hwmon does and what interfaces of Jack are
involved.  I can find zilch information on that in the documentation of
either software, the manual pages are vague and terribly outdated and
"just read the source code", while being a possible last resort, seems
like I might be missing something here.  And if I am missing it, maybe
it warrants better visibility so that others in a similar situation
might find it easier?

Many ALSA cards have some sort of hardware mixer, and a whole lot of
them are shakier in full-duplex mode and would benefit from a hardware
monitoring solution where applicable.

So I don't think this is an "esoteric uses" only question.

> The question was what effects jackd --hwmon and/or the Ardour
> monitoring option "via Audio Driver" (discovered after the initial
> question was already posed but very likely related) have.
>
> Also the question was where information about supported cards and the
> used API to Jack were to be found since the manual page describing the
> options represented the status as of 2003 AD.

--
David Kastrup
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How does --hwmon work?

Chris Caudle
I found this reply from Paul Davis (original jackd author/designer) for
essentially the same question from many years back:

---------------------------
On Fri, Aug 27, 2010 at 3:29 PM, Niels Mayer <[hidden email]> wrote:
> Finally reading the jackd manpage again (
> http://linux.die.net/man/1/jackd ) I notice
> -H, --hwmon

Most people do not use this. It is entirely replaced by using a h/w
specific utility (such as hdspmixer or envy2ctl) to control signal
routing. The one benefit that it has is that it means that JACK
*applications* can control that kind of routing, which early in the
life of Ardour seemed kind of important. It no longer seems very
important.
If you're already using a h/w specific utility for this purpose, then
don't use -H.

> PS: likewise what does the "-M, --hwmeter" option do -- again I don't
> see any difference between this being on or off. And how would it know

it doesn't really do anything. It was a placeholder for functionality
that has never been implemented because (a) so few cards implement it
and (b) the meter is basically useless for any app other than a h/w
specific utility app (which has other mechanisms available to get the
meter values).
---------------------------

So it looks like this feature never really became common, and it appears
that the jackd hardware monitor option only works on ICE or hdsp based
cards.  Maybe a few others, but unfortunately you would have to inspect
the ALSA driver source to make sure.

On Thu, May 4, 2017 4:17 am, David Kastrup wrote:
> I am currently in the process of Frankensteining a Roland FR1b "virtual
> accordion" with soft- and hardware Midi expanders, and the Roland only
> has a single Midi connector that is either in- or output.  So when the
> registration calls for the Roland to be silent, I have to access the
> mixer programmatically.

Which mixer?  The mixer in the audio interface?  I don't fully understand
the hardware configuration you are describing.

> Since I don't want the software to be tied to a particular soundcard, a
> more generic interface that _does_ use hardware monitoring/mixing of
> some kind internally when available would seem like the best fit.

In practical terms it seems you will be tied to a particular soundcard, or
at least family of cards, since it seems only the ICE/envy24 drivers and
the RME drivers implemented this feature.  Maybe a few others, but good
luck figuring out which.

> But it's not clear to me where which stuff is being done and whether,
> say, using jack_mix_box for the Roland sound control will magically buy
> me "zero-latency" monitoring or not.

Only if the ALSA driver reports has_hw_monitoring as true.
Which driver does the Roland sound control use?

> It really depends on what --hwmon does and what interfaces of Jack are
> involved.

From a quick look at the jackd code it appears that the ALSA backend of
jackd queries the ALSA driver, and if the drivers reports
has_hw_monitoring then it sets the hw_monitoring property of the driver to
on if requested.  If the driver reports has_hw_monitoring as false then it
does nothing.

> the manual pages are vague and terribly outdated and

That is unfortunately true.  For most uses for which jack was designed, it
does what it is needed and has fallen into a barely maintained "just keep
it compiling" kind of state.  There is a new jackd maintainer, but I think
just working on it part time, and basic things like keeping man pages and
web pages up to date is not being done currently.

> Many ALSA cards have some sort of hardware mixer

Yes, but most of them have utilities for configuring the hardware mixer.
The hwmon option to jackd is just on/off, it doesn't give any way to
control the gain of the connection, or the routing if there are multiple
inputs and multiple outputs.  I think the jackd option never caught on
because it was too limited to be useful.

--
Chris Caudle


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How does --hwmon work?

David Kastrup
"Chris Caudle" <[hidden email]> writes:

> I found this reply from Paul Davis (original jackd author/designer) for
> essentially the same question from many years back:
>
> ---------------------------
> On Fri, Aug 27, 2010 at 3:29 PM, Niels Mayer <[hidden email]> wrote:
>> Finally reading the jackd manpage again (
>> http://linux.die.net/man/1/jackd ) I notice
>> -H, --hwmon
>
> Most people do not use this. It is entirely replaced by using a h/w
> specific utility (such as hdspmixer or envy2ctl) to control signal
> routing.

The hardware specific utilities do a much less versatile job than Ardour
could (for example, I can control Ardour using my nanoKontrol device,
but not hdspmixer).  And having one utility for every card is a hopeless
feat.

> The one benefit that it has is that it means that JACK *applications*
> can control that kind of routing, which early in the life of Ardour
> seemed kind of important. It no longer seems very important.  If
> you're already using a h/w specific utility for this purpose, then
> don't use -H.

That doesn't really tell what the option does.  It just provides a bit
of history around it.  And I suspect from the options Ardour provides me
when using a Hammerfall card independent of the presence or absence of
--hwmon that --hwmon is also a noop as an option and essentially
unconditionally enabled when the card supports it.

> ---------------------------
>
> So it looks like this feature never really became common, and it
> appears that the jackd hardware monitor option only works on ICE or
> hdsp based cards.  Maybe a few others, but unfortunately you would
> have to inspect the ALSA driver source to make sure.

And likely the Ardour source to figure out what it does.  Assuming that
it is related to the "via Audio Driver" monitoring option.

> On Thu, May 4, 2017 4:17 am, David Kastrup wrote:
>> I am currently in the process of Frankensteining a Roland FR1b "virtual
>> accordion" with soft- and hardware Midi expanders, and the Roland only
>> has a single Midi connector that is either in- or output.  So when the
>> registration calls for the Roland to be silent, I have to access the
>> mixer programmatically.
>
> Which mixer?  The mixer in the audio interface?

Yes.  The audio interface gets the line outs from the Roland and
provides a line out of itself.  This line out is mixed from the output
of the Aeolus organ and the line outs from the Roland.  When the Midi
program switches from the Roland signal that it is changed to organ
mode, its key signals are routed to the Aeolus organ and the Roland line
outs are switched off in the audio interface mixer so that the Roland's
undesired organ patches don't mess with the output from Aeolus.

This allows replacing just part of the Roland's patches with stuff
synthesized on my computer while retaining the Roland's selection and
registration mechanisms and switches.

>> Since I don't want the software to be tied to a particular soundcard,
>> a more generic interface that _does_ use hardware monitoring/mixing
>> of some kind internally when available would seem like the best fit.
>
> In practical terms it seems you will be tied to a particular
> soundcard, or at least family of cards, since it seems only the
> ICE/envy24 drivers and the RME drivers implemented this feature.

So what?  If Jack transparently reverts to software monitoring in its
realtime thread when hardware monitoring is not available, the program
works as well as possible on either hardware.

> Maybe a few others, but good luck figuring out which.

I consider that Jack's job.  That would be what makes sense.

>> But it's not clear to me where which stuff is being done and whether,
>> say, using jack_mix_box for the Roland sound control will magically
>> buy me "zero-latency" monitoring or not.
>
> Only if the ALSA driver reports has_hw_monitoring as true.  Which
> driver does the Roland sound control use?

Uh what?  The Roland is an accordion.  It has an analog line out and a
digital Midi out.  It does not accept any feedback during normal
operation.

>> It really depends on what --hwmon does and what interfaces of Jack
>> are involved.
>
> From a quick look at the jackd code it appears that the ALSA backend
> of jackd queries the ALSA driver, and if the drivers reports
> has_hw_monitoring then it sets the hw_monitoring property of the
> driver to on if requested.

That's one bit?  Uh, that makes it hard to guess what it even does on a
multi-channel card like the RME.

> If the driver reports has_hw_monitoring as false then it does nothing.
>
>> the manual pages are vague and terribly outdated and
>
> That is unfortunately true.  For most uses for which jack was designed, it
> does what it is needed and has fallen into a barely maintained "just keep
> it compiling" kind of state.  There is a new jackd maintainer, but I think
> just working on it part time, and basic things like keeping man pages and
> web pages up to date is not being done currently.
>
>> Many ALSA cards have some sort of hardware mixer
>
> Yes, but most of them have utilities for configuring the hardware
> mixer.

Not really.  Most of them have amixer settings, and there are generic
utilities that work with those.  But those utilities, again, don't have
control interfaces feeding into them like Ardour has.  And jack_mixer,
if I understand correctly, only does software volume control.

> The hwmon option to jackd is just on/off, it doesn't give any way to
> control the gain of the connection, or the routing if there are
> multiple inputs and multiple outputs.  I think the jackd option never
> caught on because it was too limited to be useful.

Well, maybe.  In my ideal world, I'd tell Jack which channel I want to
map to which output with which gain, and if it can map this to hardware,
it will, and otherwise use software.  But of course this would require
putting this kind of thing into Jack API and responsibility in the
first place.  Jack can already connect in- and outputs.  Just the gain
is missing...

--
David Kastrup
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How does --hwmon work?

Ralf Mardorf
On Fri, 05 May 2017 01:52:35 +0200, David Kastrup wrote:

>"Chris Caudle" <[hidden email]> writes:
>> The hwmon option to jackd is just on/off, it doesn't give any way to
>> control the gain of the connection, or the routing if there are
>> multiple inputs and multiple outputs.  I think the jackd option never
>> caught on because it was too limited to be useful.  
>
>Well, maybe.  In my ideal world, I'd tell Jack which channel I want to
>map to which output with which gain, and if it can map this to
>hardware, it will, and otherwise use software.  But of course this
>would require putting this kind of thing into Jack API and
>responsibility in the first place.  Jack can already connect in- and
>outputs.  Just the gain is missing...

Yes, jack already could do the I/O connections, but jack can't do the
hardware routing, so not only a gain control is missing for what you
want to get. The abilities of audio interfaces are very different. You
seem to have an idea of what does fit good to your personal needs, but
what you want to get seemingly is very unusual. The routing of hardware
monitoring could be much too complex, that's why hdspmixer and/or
mixing consoles are usually used.

Regards,
Ralf
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How does --hwmon work?

David Kastrup
Ralf Mardorf <[hidden email]> writes:

> On Fri, 05 May 2017 01:52:35 +0200, David Kastrup wrote:
>>"Chris Caudle" <[hidden email]> writes:
>>> The hwmon option to jackd is just on/off, it doesn't give any way to
>>> control the gain of the connection, or the routing if there are
>>> multiple inputs and multiple outputs.  I think the jackd option never
>>> caught on because it was too limited to be useful.  
>>
>>Well, maybe.  In my ideal world, I'd tell Jack which channel I want to
>>map to which output with which gain, and if it can map this to
>>hardware, it will, and otherwise use software.  But of course this
>>would require putting this kind of thing into Jack API and
>>responsibility in the first place.  Jack can already connect in- and
>>outputs.  Just the gain is missing...
>
> Yes, jack already could do the I/O connections, but jack can't do the
> hardware routing, so not only a gain control is missing for what you
> want to get.

The typical sound card already has labelled ALSA controls for it (I
think the Firewire stack tends to moving to userspace applications for
mixer controls, but even those could be called from a Jack-controlled
thread).  The labels of those controls are just not associated with
standard meanings, but that could be rectified using asoundrc and its
ilk.  Basically the bits are there but not connected.

> The abilities of audio interfaces are very different. You seem to have
> an idea of what does fit good to your personal needs, but what you
> want to get seemingly is very unusual.

Controlling mixers other than manually?  If that were very unusual, Midi
control surfaces would not be as abundant as they are.

> The routing of hardware monitoring could be much too complex, that's
> why hdspmixer and/or mixing consoles are usually used.

Analog mixing consoles are on their way out.  Digital control surfaces
are everywhere and it's a bit strange that in the Linux DAW world they
cannot make it through to the hardware.

--
David Kastrup
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How does --hwmon work?

Ralf Mardorf
On Fri, 05 May 2017 09:42:01 +0200, David Kastrup wrote:
>Digital control surfaces are everywhere and it's a bit strange that in
>the Linux DAW world they cannot make it through to the hardware.

Hi,

you could mix a song using a control surface and/or automation of
software such as Ardour. There unlikely is a reason to use a control
surface and/or automation for hardware monitoring, hdspmixer allows to
save and load as much presets as you want, 8 presets are available even
without loading.

A lot of Linux hardware issues are caused by the missing support of the
hardware vendors. However, what you want to get is already an issue, due
to the differences of audio interfaces, even if the vendor should
support Linux.

You expect the recording software to use the audio interface's mixer
"like this", but if "like this" shouldn't be supported to "fallback to
that".

An AIO solution, bundled software + hardware could provide what you
want to get, in a professional way. I doubt this would work very good,
if software needs to care about what ever audio interface should be
connected.

A compromise might be to control the DAW mixer and independently to
control the hardware mixer, too, IOW something like hdspmixer
controlable by MIDI events. Do a lot of people need it? If so, is
somebody willing to add MIDI to e.g. hdspmixer? EQs, Reverb and delay
would be nice for the hardware monitoring, too and indeed, proprietary
software for a lot of audio interfaces provide this. If it's provided
by the vendor of your audio interface for Windows and/or Apple
platforms, you should ask the vendor to support Linux, too ;).

2 Cents,
Ralf
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How does --hwmon work?

David Kastrup
Ralf Mardorf <[hidden email]> writes:

> On Fri, 05 May 2017 09:42:01 +0200, David Kastrup wrote:
>>Digital control surfaces are everywhere and it's a bit strange that in
>>the Linux DAW world they cannot make it through to the hardware.
>
> Hi,
>
> you could mix a song using a control surface and/or automation of
> software such as Ardour. There unlikely is a reason to use a control
> surface and/or automation for hardware monitoring, hdspmixer allows to
> save and load as much presets as you want, 8 presets are available even
> without loading.
>
> A lot of Linux hardware issues are caused by the missing support of
> the hardware vendors. However, what you want to get is already an
> issue, due to the differences of audio interfaces, even if the vendor
> should support Linux.

Sigh.  Alsa already offers fairly generic access to soundcard mixers
with the alsamixer and amixer commands.

> You expect the recording software to use the audio interface's mixer
> "like this", but if "like this" shouldn't be supported to "fallback to
> that".
>
> An AIO solution, bundled software + hardware could provide what you
> want to get, in a professional way. I doubt this would work very good,
> if software needs to care about what ever audio interface should be
> connected.

Sigh.  I propose precisely that end user software should _not_ need to
care about whatever audio interface is connected.  That's one of the
points of Jack and ALSA.  Standard APIs to functionality that might be
implemented differently at the driver end.

> A compromise might be to control the DAW mixer and independently to
> control the hardware mixer, too, IOW something like hdspmixer
> controlable by MIDI events. Do a lot of people need it?

Not enough if _every_ _single_ soundcard needs its own mixer application
coded from scratch.  If one creates a common useful Jack API for gained
connections that one mixer application can work with, there will
certainly be enough need to provide a Midi controlled mixer capable of
using hardware mixing where available.

> If so, is somebody willing to add MIDI to e.g. hdspmixer?

The RME Hammerfall is dated (not that it doesn't hold its own pretty
well but you still need to hook it up with preamps and then stuff starts
getting bulky), and hdspmixer is pretty cumbersome to use.  I'd rather
whip up a few Ardour mixers for the connections I actually need and have
them delegate to hardware where feasible.

> EQs, Reverb and delay would be nice for the hardware monitoring, too
> and indeed, proprietary software for a lot of audio interfaces provide
> this.

For hardware monitoring?  Hardly.  At driver level?  Maybe.  But then
it's not fundamentally different to Jack plugins.

--
David Kastrup
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How does --hwmon work?

Ralf Mardorf
On Fri, 05 May 2017 19:14:52 +0200, David Kastrup wrote:
>> A compromise might be to control the DAW mixer and independently to
>> control the hardware mixer, too, IOW something like hdspmixer
>> controlable by MIDI events. Do a lot of people need it?  
>
>Not enough if _every_ _single_ soundcard needs its own mixer
>application coded from scratch.  If one creates a common useful Jack
>API for gained connections that one mixer application can work with,
>there will certainly be enough need to provide a Midi controlled mixer
>capable of using hardware mixing where available.

That's absurd, since the different sound cards provide completely
different routing features. If you mix a project with a DAW, then the
software mixer should be completely separated from the hardware mixer.

If you want to get all in one, consider to just use the I/Os of an
audio interface and to buy the right tool for that task, a separated
mixing console [1].

>> EQs, Reverb and delay would be nice for the hardware monitoring, too
>> and indeed, proprietary software for a lot of audio interfaces
>> provide this.  
>
>For hardware monitoring?  Hardly.  At driver level?  Maybe.  But then
>it's not fundamentally different to Jack plugins.

Yes, hardware monitoring done with an external mixing console [1] very
often is done by adding effects to the monitor signal, so some
proprietary audio interface software provides this for the audio
interface's hardware monitoring, too.

The audio interface's hardware monitoring is done at driver level, while
the software could be split to the driver and mixer software, the
access to the hardware monitoring still is part of the driver.

Jack plugins? Driver level? Jack is a sound server using a backend such
as ALSA.

Keep in mind that it's common practise to use real mixing consoles [1]
and/or to use the audio interface's hardware mixer in addition to the
DAW's mixer. Most people do not have the same needs as you have got
[2].

I'm using hdspmixer for my RME audio interface. My Focusrite isn't
supported, so I'm using it class compliant, without the option to have
access to the hardware monitoring. Actually a driver for other Focusrite
interfaces from the same series exists and I much likely only need to
add an ID to the driver's source code and build it, to get access to
the hardware monitoring, but I simply don't need it. A lot of people
don't need hardware monitoring provided by the audio interface. Those
who need it, usually like to use the separated audio interface's
hardware mixer. I never heard from anybody who shares the same need as
yours. There are for sure people who share your wish, but you will not
find that many who do so, that seemingly is the reason that nobody
wrote the code you wish to have.

Regards,
Ralf

[1] not necessarily an analog mixing console, it just means that it is
a mixing console and not just a remote control. However, even a
separated mixing console, analog as well as digital, could send and
receive data from a DAW or use it's own automation sequencer synced to
the DAW. OTOH a cheap mixing console already could be used to separate
the real mix, probably just done by a software mixer and the monitor
mix, done by the cheap mixing console. So you could put the remote
control for the DAW's mixer and the mixing console to each other. If you
want to do the complete mix with a mixing console, you have to get one
in a different price segment, to get professional sound quality, but
then you really get all in one.

[2]
On Thu, 4 May 2017 17:35:24 -0500, Chris Caudle wrote:

>I found this reply from Paul Davis (original jackd author/designer) for
>essentially the same question from many years back:
>
>---------------------------
>On Fri, Aug 27, 2010 at 3:29 PM, Niels Mayer <[hidden email]> wrote:
>> Finally reading the jackd manpage again (
>> http://linux.die.net/man/1/jackd ) I notice
>> -H, --hwmon  
>
>Most people do not use this. It is entirely replaced by using a h/w
>specific utility (such as hdspmixer or envy2ctl) to control signal
>routing. The one benefit that it has is that it means that JACK
>*applications* can control that kind of routing, which early in the
>life of Ardour seemed kind of important. It no longer seems very
>important.
>If you're already using a h/w specific utility for this purpose, then
>don't use -H.
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How does --hwmon work?

David Kastrup
Ralf Mardorf <[hidden email]> writes:

> On Fri, 05 May 2017 19:14:52 +0200, David Kastrup wrote:
>>> A compromise might be to control the DAW mixer and independently to
>>> control the hardware mixer, too, IOW something like hdspmixer
>>> controlable by MIDI events. Do a lot of people need it?  
>>
>>Not enough if _every_ _single_ soundcard needs its own mixer
>>application coded from scratch.  If one creates a common useful Jack
>>API for gained connections that one mixer application can work with,
>>there will certainly be enough need to provide a Midi controlled mixer
>>capable of using hardware mixing where available.
>
> That's absurd, since the different sound cards provide completely
> different routing features.

Which is why it makes good sense to have jackd fall back to software
gain when the card's known controls don't allow for using hardware.
That way you don't need specialized software to make best use of your
hardware.

> If you mix a project with a DAW, then the software mixer should be
> completely separated from the hardware mixer.

Because what?  We don't separate software and hardware plugins either.
They are available as jack ports.  So why should a connection not be
hardware where supported?

> If you want to get all in one, consider to just use the I/Os of an
> audio interface and to buy the right tool for that task, a separated
> mixing console [1].

A separated mixing console takes a whole lot more space than a
nanoKontrol if you are trying to get to a conference by train.

I mean, I'd get the "who's gonna do it" argument.  But this is going
more in the "let's keep things as badly interoperable as they are
because that is the way of our fathers" direction.

All I hear is "that is silly", "that is absurd", "that's not the right
way to do things".  But no actual argument why.

>>> EQs, Reverb and delay would be nice for the hardware monitoring, too
>>> and indeed, proprietary software for a lot of audio interfaces
>>> provide this.  
>>
>>For hardware monitoring?  Hardly.  At driver level?  Maybe.  But then
>>it's not fundamentally different to Jack plugins.
>
> Yes, hardware monitoring done with an external mixing console [1] very
> often is done by adding effects to the monitor signal, so some
> proprietary audio interface software provides this for the audio
> interface's hardware monitoring, too.
>
> The audio interface's hardware monitoring is done at driver level, while
> the software could be split to the driver and mixer software, the
> access to the hardware monitoring still is part of the driver.
>
> Jack plugins? Driver level? Jack is a sound server using a backend
> such as ALSA.

Jack prefers working at realtime priority and some plugins may do so as
well, possibly in relation to priority elevation.  Unfettered hardware
access is not necessary for the latency aspects.

> I'm using hdspmixer for my RME audio interface. My Focusrite isn't
> supported, so I'm using it class compliant, without the option to have
> access to the hardware monitoring. Actually a driver for other
> Focusrite interfaces from the same series exists and I much likely
> only need to add an ID to the driver's source code and build it, to
> get access to the hardware monitoring, but I simply don't need it. A
> lot of people don't need hardware monitoring provided by the audio
> interface.

Many affordable USB-level interfaces are quite more prone to xruns if
you drive them in full duplex.  So particularly on consumer hardware
(and that's what most people use) making use of available hardware
monitoring solutions employing the builtin mixers would make good sense.

Physical controllers are nice to use for that, and this is why software
like Ardour supports digital controllers which can be used for mixing
instead of a hardware mixer.  I don't see the point in maintaining
software/hardware barriers that should only be crossed using
hard-tailored rather than general-purpose software.

--
David Kastrup
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How does --hwmon work?

Ralf Mardorf
On Sat, 06 May 2017 10:41:53 +0200, David Kastrup wrote:
>A separated mixing console takes a whole lot more space than a
>nanoKontrol if you are trying to get to a conference by train.  

A harp takes less space than a drum kit. Use the luggage check-in
instead of handluggage or simply use a van. IOW you need to do what's
appropriate for you business. It also might be possible to not to take
the drum kit or mixing console with you, but to borrow one at the
location where you need it. If you fly from Germany to the USA, you
usually don't take your car with you, you usually would borrow one from
rent-a-car.

On Sat, 06 May 2017 10:41:53 +0200, David Kastrup wrote:
>All I hear is "that is silly", "that is absurd", "that's not the right
>way to do things".  But no actual argument why.  

You ignore the arguments. 1. Different audio interfaces provide
completely different routing capabilities, so what you want to get
isn't that easy to do, if at all. 2. Not a lot of people have the same
needs as you have got. Most people want to have the audio interface's
hardware mixer separated from the DAW's software mixer, let alone those
who simply use the I/Os of the audio interface and a mixing console.

Note! If you mix the DAW's software mixer with the audio interfaces
mixer, you get a hybrid, you could add effects to the mix, but not to
the monitor mix. The only way to get a real all in one solution is just
using the audio interfaces I/Os and to do the complete mix using a
mixing console.

Regards,
Ralf
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How does --hwmon work?

Ralf Mardorf
On Sat, 6 May 2017 11:10:26 +0200, Ralf Mardorf wrote:

>On Sat, 06 May 2017 10:41:53 +0200, David Kastrup wrote:
>>A separated mixing console takes a whole lot more space than a
>>nanoKontrol if you are trying to get to a conference by train.    
>
>A harp takes less space than a drum kit. Use the luggage check-in
>instead of handluggage or simply use a van. IOW you need to do what's
>appropriate for you business. It also might be possible to not to take
>the drum kit or mixing console with you, but to borrow one at the
>location where you need it. If you fly from Germany to the USA, you
>usually don't take your car with you, you usually would borrow one from
>rent-a-car.

PS:

When I was for orchestra recordings in Berlin, the broadcasting company
did use their own recording halls, but borrowed an audio recording
studio van from France and fly in the audio engineer from the USA. Some
things simply can't be done with a KORG nanoKONTROL and a computer.
Your one-man show approach is unusual, audio engineering usually is done
by a team and with equipment that doesn't fit into handluggage.

The studio-in-a-box is very good, but the size as well as the price
limits a few things.
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How does --hwmon work?

Fons Adriaensen-3
On Sat, May 06, 2017 at 11:27:31AM +0200, Ralf Mardorf wrote:

> When I was for orchestra recordings in Berlin, the broadcasting company
> did use their own recording halls, but borrowed an audio recording
> studio van from France and fly in the audio engineer from the USA. Some
> things simply can't be done with a KORG nanoKONTROL and a computer.

For anything non-trivial, just count the number of mic stands and
kilometers of cable you'll need and then work out if that fits in
your cabin luggage :-)

Ciao,

--
FA

A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How does --hwmon work?

Ralf Mardorf
On Sat, 6 May 2017 10:00:41 +0000, Fons Adriaensen wrote:
>On Sat, May 06, 2017 at 11:27:31AM +0200, Ralf Mardorf wrote:
>> Some things simply can't be done with a KORG nanoKONTROL
>> and a computer.  
>
>For anything non-trivial, just count the number of mic stands and
>kilometers of cable you'll need and then work out if that fits in
>your cabin luggage :-)

Exactly!

So my guess is, that David does something more or less simply that
requires hardware monitoring, hence hdspmixer with it's 8 presets for
most of us, would be all we need. Neither the old, nor the new KORG
nanoKONTROL provides much scenes and channels, so it anyway wouldn't be
comfortable to use a nanoKONTROL to do the main mix, as well as the
monitoring. However, we don't now what he wants to do, that requires
hardware monitoring, so it's just guessing.

Regards,
Ralf
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How does --hwmon work?

David Kastrup
In reply to this post by Ralf Mardorf
Ralf Mardorf <[hidden email]> writes:

> On Sat, 06 May 2017 10:41:53 +0200, David Kastrup wrote:
>>A separated mixing console takes a whole lot more space than a
>>nanoKontrol if you are trying to get to a conference by train.  
>
> A harp takes less space than a drum kit. Use the luggage check-in
> instead of handluggage or simply use a van. IOW you need to do what's
> appropriate for you business. It also might be possible to not to take
> the drum kit or mixing console with you, but to borrow one at the
> location where you need it. If you fly from Germany to the USA, you
> usually don't take your car with you, you usually would borrow one
> from rent-a-car.

Sure, and professionals don't use Ardour or GNU/Linux (or Windows 10)
either but custom hardware and systems.

But this is "jack-devel" so it does not matter what "professionals" do
but rather what users of Jack do.

> On Sat, 06 May 2017 10:41:53 +0200, David Kastrup wrote:
>>All I hear is "that is silly", "that is absurd", "that's not the right
>>way to do things".  But no actual argument why.  
>
> You ignore the arguments.

I'd use the term "disspell" instead of "ignore".

> 1. Different audio interfaces provide completely different routing
> capabilities, so what you want to get isn't that easy to do, if at
> all.

Sorry, but that's just handwaving.  An audio interface will either be
able to route some input to some output with a given volume or not.  The
API to jack (or something doing that kind of job for the connection
management on its behalf) would just request the connection and would
not need to know how it was going to be established.  Many many
soundcards already provide amixer controls that can be used for this
functionality if you know how, and the "if you know how" part can be
described in a database.

As the database grows, more cards will transparently support hardware
monitoring.

It most definitely _is_ easy to do since the hard work is in the ALSA
controls of individual drivers (or even other kinds of command line
utilities used for accessing mixers) and those are already there for a
whole lot of cards.

> 2. Not a lot of people have the same needs as you have got.

And because different people have different needs, flexibility is a bad
idea?

I don't buy it.

> Note! If you mix the DAW's software mixer with the audio interfaces
> mixer, you get a hybrid, you could add effects to the mix, but not to
> the monitor mix.

Not without the system reverting back to software.  So?  If you were
recording from a Firewire card to a Firewire hard disk, in old times the
data did not even touch your computer (Firewire interfaces are a
security nightmare because of that) if the software was smart enough to
notice that it did not actually need to access the data.

That kind of "let the hardware do the job on its own whenever it can"
mind frame was what made Firewire the choice for professional work for a
really long time.

So the user notices that monitoring with effects leads to larger time
lag and larger CPU load and higher likelihood of dropouts.  He has a
choice then.  He can switch off the effects.

> The only way to get a real all in one solution is just using the audio
> interfaces I/Os and to do the complete mix using a mixing console.

I repeat: analog consoles are dying out.  People use digital
controllers.

It's just frustrating that all the _actual_ work is already done but
there is no way to plug the pieces together except for making up your
own makeshift solution that will benefit noone else.

--
David Kastrup
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
123
Loading...