[Jack-Devel] Individual gain for ports

[Thomas Brand]

On Tue, March 26, 2019 23:25, Thomas Brand wrote:
> On Tue, March 26, 2019 23:02, Robin Gareus wrote:
>
>> On 3/26/19 11:33 PM, John Rigg wrote:
>>
>>
>>> On Tue, Mar 26, 2019 at 10:12:32PM +0100, Kjetil Matheussen wrote:
>>>
>>>
>>>> On Tue, Mar 26, 2019 at 10:01 PM Fons Adriaensen
>>>> <fons at linuxaudio.org> wrote:
>>>>
>>>>
>>>>>
>>>>> The VERY LAST thing I'd want in such a system is a gain control
>>>>> on each Jack connection. One very big advantage of digital
>>>>> connections, be they MADI, ADAT, Jack, or Dante, is that signal
>>>>> levels at all inputs and outputs are exactly defined and can't
>>>>> change. Setting up a a similar system using analog connections
>>>>> with variable gains would be a real nightmare.
>>>>>
>>>>
>>>> Sure, I'm just saying that extending jack with a volume control for
>>>>  each connection would be a good thing, for those who need it,
>>>> which I guess would be the most of us. You are of course free not to
>>>> use it if you don't need it.
>>>
>>> If anyone does this please make turning it off a compile option.
>>> I can see it causing big problems in a complex setup.
>>>
>>>
>>>
>>
>> and disable it by default and add excessive warnings to not enabled it
>> :)
>>
>>
>>
>>
>> When this is implemented there are no zero-copy shared buffers anymore.
>>  Port buffers have to pass through a gain-stage first.
>>
>>
>>
>> Also, direct client-to-client wakeup will not be possible anymore. A
>> client first has to call some gain-stage or return execution to jackd to
>>  apply the gain. This adds an extra context switch.
>>
>> Last but not least, gain-changes should be gradual, free of zipper
>> noise, so there's more complexity.
>>
>> One of JACK's main concepts was that it provides a mechanism (not
>> policy). That's also why ports don't include delaylines to compensate
>> for latency. JACK is supposed to just pass data around and make
>> information available, not process data.
>>
>>
>> That being said, you can probably achieve what you want using an
>> internal-client that implements a gain-stage. Then insert that in
>> strategic places. Perhaps use the meta-data API to configure it, that
>> would also get around the issue with port-ownership to control it.
>>
>
> I had doubts about *when* port gain would be applied, and what you say
> Robin makes it clear, basically all of how client ports are ordered for
> processing one cycle could potentially be affected, and the smart aspects
> therein would be in question.
>
> If ports would have that feature, the next desire would be to automate
> it, and it's easy to imagine more DSP that JACK could do, and then we'd
> move more and more client work into the server. Instead scaling the signal
> (or
> any other DSP) should clearly be something that only non-servers should
> perform IMO, that are clients (normal or internal).
>
> For a simple mixer: loading an example FAUST script and render a jack
> client  (without ever touching a compiler, online) isn't too hard either :)
>
>
> Another note, we can imagine that a metadata property flags a port with a
>  coefficient, and then client can scale it (as a first or last DSP step)
> accordingly. Any thoughts?
>
>

Scaling a jack connection is cutting the connection, adding a scaler, then
do two new connections. It can be looked at as expensive, then again if
such a feature is needed for many channels, then a mixer is a good match
to do it as a client.

Going from cut connection, add client, re-connect (basically a
man-in-the-middle scenario): a new example client could make this task
simple, for a specific kind of jack client (1 audio in, 1 audio out).
Something along

jack_connect_mim porta portb mim_client

Say mim can be amplifier (not limited to), for one single line of audio.
It is a regular client and a tool would just help to put it in place in
the graph. Thinking further, it should be possible to remove such
man-in-the-middle again and re-create the original connection. Maybe tool
can be smart and only consider mim clients that indicate via metadata to
be useful for it. These are all not yet fully baked out ideas.