[Jack-Devel] jackd and volume control

[Tobias Hoffmann]

On 28/03/19 22:27, Kjetil Matheussen wrote:
> On Thu, Mar 28, 2019 at 9:54 PM Filipe Coelho<falktx at gmail.com>  wrote:
>> On 28.03.2019 21:27, Kjetil Matheussen wrote:
>>> On Wed, Mar 27, 2019 at 8:55 PM Filipe Coelho<falktx at gmail.com>  wrote:
>>>> On 27.03.2019 19:22, Holger Marzen wrote:
>>>>> As far as I understood there are 3 opinions:
>>>>>
>>>>> 1.) Don't change anything
>>>>> 2.) Add some API-calls to control the volume of every port
>>>>> 3.) Add an API-call to control the volume of system:playback_*
>>>> As the current jack maintainer I can already give you the heads up.
>>>> It is option 1, no such API is going to be added, ever.
>>>>
>>> So, what do you think is wrong with number 2? It's a simple
>>> modification to jack that might give a lot of benefit. Also, it would
>>> certainly solve problem that it's impossible to create a client mixer
>>> for jack now. Pulsaudio/window/osx has it, it's a very natural tool to
>>> expect.
>> This has been debated to death already, you are just not willing to
>> listen and quickly dismiss the other side.
> Maybe, but I don't understand why this should be a problem. I don't
> even understand why you need an extra buffer since each input port
> already has a buffer. An input port is not used by other ports after
> it's been mixed down in the current cycle, right? So why is it such a
> problem to apply connection volume while mixing down input ports? The
> buffer is not going to be used by any others than the client code
> anyway. And even if that input port buffer is going to be used later
> in the same cycle, it shouldn't be a problem to return a non-shm
> buffer specially mixed for the client when the client calls
> jack_port_get_buffer. So to me, it seemed like Robin just had
> overthought the problem.

AFAIUI the thing is, a jack-internal implementation would be quite 
limited. And when thinking of analog gear, you would certainly split a 
channel into two, but you would seldom push two channels into one input, 
without extra gear (and please don't bring up these strange 
reverse-Y-cables with resistors in it...). Instead, some people seem to 
even want to doing special dsp processing when adding together multiple 
channels... And with MIDI, adding together two channels is even rather 
different than adding Audio - or adding other type of data (when you 
think of Jack as a general-purpose-data interconnect)

With a system:playback_* that only allows a single connection to it 
would probably simplify the whole thing, because even the casual Jack 
user would already be running (one of many) mix-down clients, of which 
most(all?) would certainly include a decent volume control.

Instead, Jack chose the other direction, one could say: as concession to 
the users, of doing some trivial mixdown, but now people want even more 
(and probably more, and even more, ... ).

The other bad habit that sprung out of this decision is, that the 
connection-graph stayed rather low-level, and features like meta-data 
came rather late and are very slowly adapted. As soon as you use jack 
anything more than a few channels, you'll use a graphical "connection 
manager", a.k.a. session manager
(well, with big installations things become so overwhelming, that 
completely computer-controlled / scripted connections will be used).
But think of the alternative: When even trivial mixdown would require a 
client, I propose that things would have evolved rather differently: 
Because of the need for effective graph management, jack would include a 
(thought-thru) solution, that would easily allow to "insert" a client 
into existing connections and to (e.g.) auto-connect clients to the 
correct mix-down client (instead of the almost hardcoded 
system:playback_* mess of today).

So, my hope is still for (much) better and standardized high-level 
graph-management. And with that in place, the GUI, that any gain-control 
would somehow need, would easily be able to insert itself into the 
relevant connections and do the mixdown (without having to add more dsp 
stuff into jack).
...Q: "But Jack does this RPCy stuff so that the GUI would not have to 
run continuously! (And thus gain control should be implemented into the 
server)".
...A: "(... and systemd has dbus!). Well, here's an idea: Why not use 
Jack as *middleware* for passing control values between gui and (e.g.) 
mixdown-client?"

Let sanity prevail!

   Tobias