[Jack-Devel] How does --hwmon work?

David Kastrup dak at gnu.org
Fri May 5 01:52:35 CEST 2017


"Chris Caudle" <chris at chriscaudle.org> 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



More information about the Jackaudio mailing list