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

[David Kastrup]

David Kastrup <dak at gnu.org> writes:

> Ralf Mardorf <ralf.mardorf at alice-dsl.net> writes:
>
>> On Sat, 06 May 2017 16:47:39 +0200, David Kastrup wrote:
>>>Jack might not be the solution, perhaps.  But what could be?
>>
>> And once you found a way to compound the DAW mixer with the audio
>> interface's mixer, write a good manual that allows the less versed
>> user, as well as the professional user to understand why the DAW mixer
>> is that different and does work in obscure ways, when using different
>> audio interfaces and how to get back a sane DAW mixer with a clearly
>> separated audio interface mixer, for those who are used to sane
>> work-flows.
>
> It's not like the "via Audio Driver" option for monitoring in Ardour is
> documented in its manual in any way, so sane people seem to prefer not
> having any information in the manuals that might be useful but
> detracting from sane work-flows.
>
> I wouldn't know.  I find sane people hard to understand.

Ok, looking at the source code in Ardour shows that "via Audio Driver"
leads to a setting HardwareMonitoring that causes differences in the
code paths amounting to the additional call

                        (*chan)->source.request_input_monitoring (!(_session.config.get_auto_input() && rolling));

in the loop

                for (ChannelList::iterator chan = c->begin(); chan != c->end(); ++chan) {
                        (*chan)->source.request_input_monitoring (!(_session.config.get_auto_input() && rolling));
                        capturing_sources.push_back ((*chan)->write_source);
                        Source::Lock lock((*chan)->write_source->mutex());
                        (*chan)->write_source->mark_streaming_write_started (lock);
                }

in AudioDiskStream::prep_record_enable ().  And that seems to lead
(eventually) to jack_port_request_monitor.

Which depends on the capability described as:

    JackPortCanMonitor if JackPortCanMonitor is set, then a call to jack_port_-
    request_monitor() makes sense.
    Precisely what this means is dependent on the client. A typical result of
    it being called with TRUE as the second argument is that data that would
    be available from an output port (with JackPortIsPhysical set) is sent to a
    physical output connector as well, so that it can be heard/seen/whatever.
    Clients that do not control physical interfaces should never create ports with
    this bit set.

So the Ardour option basically is provided when Jack tells Ardour "this
output would be interested to know in the context of monitoring when you
would be getting into a recording situation in order to make the source
also available physically".

Something like that.  But what should actually happen is unclear.

The RME Totalmix block diagrams show a "Loopback" switch that allows
recording the hardware outputs (which are the mixer outputs created from
the various inputs as well as the sent signals into the sound cards)
rather than the inputs directly.  But that would be sort of the reverse
of monitoring (instead of providing the inputs also as outputs it
provides the outputs in place of the inputs).

So I'd probably have to read the ALSA driver and Jackd source codes to
figure out what happens when doing "record enable".  Or I experiment
with the hardware.

-- 
David Kastrup