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

David Kastrup dak at gnu.org
Sat May 6 16:47:39 CEST 2017


Tobias Hoffmann <lfile-list at thax.hardliners.org> writes:

> On 06/05/17 13:08, David Kastrup wrote:
>
>> 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.
>
> This thread is going on for much too long already.

It wasn't getting anywhere, though.

> Here is an actual datapoint wrt. current Hardware:
> Take the Focusrite Scarlett class of USB-based Audio Devices (for
> which I happened to write the Alsa-mixer driver [based on previous
> work by Robin Gareus]).
> These devices use the standardized USB-HID-Endpoints for the audio,
> but use custom endpoints for accessing the Mixer. Therefore Audio-I/O
> did work out of the box, with the standard linux driver, but
> Mixer-control needs an hardware-specific driver, for reasons that
> might become clear in the following exposition.
>
> For the Scarlett 18i8 there are 18 Inputs and 8 Outputs. Internally
> there is a 18x8 mixing matrix (the same(!) matrix size is actually
> used for variants with less actual I/O ...).
> Actually, the above mentioned I/O numbers are the physical
> connectors. Regarding USB, there are also 18 Capture-"Endpoints" and 8
> Playback-"Endpoints".
> Now the thing is, these Capture/Playback-Endpoints aren't tied to a
> specific electrical I/O, but for each Matrix-Input, Physical-Output
> and Capture-Input there is a software-configurable - i.e. exposed as
> alsa mixer enum-type control - Multiplexer to choose from any of the
> available Matrix-Outputs, Physical-Inputs and Playback-Outputs (except
> you can't directly connect a Matrix-Output to a Matrix-Input).
> That's the - quite flexible - topology of the Device, which can and
> should - obviously - allow for hardware-monitoring...
>
> Let's now assume that JACK provides some kind of hardware monitoring
> support by detecting direct connections between capture-inputs and
> playback-outputs

I wasn't thinking as much about "detecting" but rather "having readily
available knowledge about the ability to ...".  "Readily available
knowledge" implies a database, and matching that database to Jackd's
topology needs does not sound like something to be done in a realtime
process.  But the per-card data might be converted into directly usable
form by some sort of daemon and handed over to Jackd.

> and instead of copying audio data on the software side chooses to
> modify the mixer instead (I don't know what --hwmon really does).

I'll try hunting it down eventually.  Would provide some closure for
this thread.

> Now how could it do that?
>
> First, it needs some kind of mapping which physical i/o corresponds to
> which mixer control. As you can see, this entirely depends on the
> device's topology. So, for a solution to be  any good, it has to
> support different topologies. There are at least "Summing" nodes,
> "Gain control" nodes, "Multiplexer" nodes, "Switch" nodes (-> Mute)
> and "Duplicate" nodes required to model current hardware. These nodes
> could be more or less arbitrarily connected (source -> sink), like a
> DAG (directed acyclic graph).
>
> Secondly, we have have to find a path through this graph from a
> certain hardware-input to a certain hardware-output. But Jack actually
> does not deal with hardware-inputs and hardware-ouputs, but with
> capture-inputs and playback-outputs.

That's its current hardware interface.  But let's not forget that Jack
also dabbles in software inputs and outputs (like aeolus:midi/in and
similar).  You are quite correct that I did not think through that
hardware-input and capture-input do not have an implied 1:1 relation.
Since Jack can also handle software-provided end points, it would seem
that the basic underlying flexibility should be there for _normal_
configurations (providing and particularly listing one Jack port for
every potential sound source available on a telephone network to a
hardware interface of my phone would certainly not work all too well as
an API).

> For the Scarlett, we know that we have to look at the capture-mux to
> find the hardware-input it is connected to (but it might even be
> connected to something else). We also look at the Playback-output and
> have to find the Hardware output. There are actually two ways a
> hardware-output could be connected to a hardware-input: Either the
> Hardware-Output-Mux directly selects a Hardware-Input, or it selects a
> Matrix-Output where some Matrix-Input is actually connected, via the
> Matrix-Input-Mux, to a given hardware-input. Notice how the device is
> perfectly capable of sending the monitoring signal to a
> hardware-output which is not connected to a capture-input. So the
> whole idea that JACK works with capture-inputs instead of physical
> hardware inputs is detrimental to what we actually want to
> achieve. But it does not stop there: To establish a new monitoring
> connection, there are now also *two* possible paths to choose from:
> Either via the mixer (might still need some MUX-reconfiguration!), or
> via the Output-Mux. Except you can't use the Output mux method if you
> want to route more than one input to the same output (i.e. sum
> them). To add another twist, the Matrix-hardware does not allow
> Mute/Unmute (unlike the Output-Masters, they can be muted). A
> hardware-specific mixer software can actually implement these by
> storing the old value and setting the gain to "0" (which actually is
> labeled -128dB, on the Scarlett). As JACK was (intentionally, AFAIK)
> designed to not provide any gain control by itself,

Well, an API for accessing something like the matrix mixer of a
Hammerfall DSP Multiface only with on/off settings would be a bad idea
(actually, even its headphone output volume can only be adjusted via the
internal mixer: IĀ don't consider that a good design choice and it has
been changed in the MultifaceĀ II, but any on/off only routing design
would likely clash with utilities and commands intended to do more
fine-grained control).

> there somewhere has to be this "magic" gain value to be used to
> "Unmute" a certain Matrix connection. While "0 dB" might seem a
> reasonable choice, it clearly falls behind the actual capabilities of
> the device and using a fixed value would certainly be an annoying
> limitation, in practice.

Agreed.

> It basically boils down to: "Who controls the mixer?"  E.g. for MUX
> settings there has to be one single master who decides how the device
> is going to be configured and who is free to make any changes, as
> required.  Any software that places itself to become that "master"
> should better work with whatever flexibility a given interface has,
> instead of arbitrary limiting it. In other words, it has to, more or
> less, support all features a device has. JACK is not - and will most
> certainly never be - able to handle such things. And IMHO it
> shouldn't. From a software-engineering standpoint, a dedicated mixer
> app as "master" is the simplest solution, and - by far - the most
> flexible.

So the question is: can we envision a unified API and access method to
access one or several utilities of that kind outside of the current
scope of Jack?  I think that being able to control mixers and routing
via Ardour mixer strips (thus also making them available for automation
within an Ardour session and for access via Midi controllers) would make
a lot of sense.

> A side node: The alsa mixer stuff is quite horrible. E.g. the ordering
> of the controls is determined by some heuristics in the user-space
> alsa libs (that takes a snd_hctl_* (hardware control) from the kernel
> and provides the snd_ctl_* an application actually works with).

I am not in disagreement here.  The one redeeming feature of ALSA mixer
control is that it exists.  Which is a whole lot better for playing
around than not existing.

[Several abominations deleted]

> Scarlett-driver simply does not support metering.  Also, during the
> process of upstreaming the driver, the "Save mixer settings to
> hardware (NVRAM)" (for standalone operation) had to go, because alsa
> just has no appropriate control element type to expose that feature of
> the device.

I wasn't going to propose that mapping everything through ALSA was the
best course.  Badly done or not, the availability of ALSA for a long
time has had an influence of the features available to some degree or
other to soundcard users.

Sometimes a bad solution is needed for the motivation and insight for
developing a better solution.

>> 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.

> For most of the history of digital music/video/..., computers were not
> fast enough to do any serious processing. So to get anywhere,
> reliably, you simply *had to* use hardware, where ever you can.
> Nowadays even digital mixer consoles tend towards software effect
> processing / plugins on general purpose CPUs instead of dedicated DSP
> chips.

But they do it in their own realtime OS rather than handing it off to a
general-purpose desktop computer to let it fight out the realtime
constraints with its applications.  "Hardware" does not mean "not using
computers" these days, more like "not using computers under user control
and responsibility".

> The earlier digital audio consoles were also quite limited by the
> hardware implementation, e.g. "You can route X to Y, but not to Z,
> because reasons". On the other hand, I believe the Focusrite Scarlett
> is so flexible, is because it's based on the xCORE chip, which has up
> 32 CPU/microcontroller cores that can easily implement tasks like
> "gain", "mux", ... - because it is all *software*. It's all about
> *controlling* latency and load - which is exactly what JACK tries to
> do.

Right.  So the question is just how to arrive at a point where most of
the slow-changing controls of a soundcard (mixers and multiplexers being
prime examples) can be accessed from an application like Ardour in a
consistent and automatable manner.

Jack might not be the solution, perhaps.  But what could be?

-- 
David Kastrup



More information about the Jackaudio mailing list