[Jack-Devel] Jack Problems

[Kjetil Matheussen]

On Wed, Mar 27, 2019 at 3:08 PM Sunset Tech <swansong.tech at gmail.com> wrote:
>
>
>
> On Wed, Mar 27, 2019, 9:18 AM Kjetil Matheussen <k.s.matheussen at gmail.com> wrote:
>>
>> On Wed, Mar 27, 2019 at 2:10 PM Sunset Tech <swansong.tech at gmail.com> wrote:
>> The point isn't that its' not that much trouble to do. The point is
>> that it would be better if there was no trouble at all doing it. It
>> would be better if there was a program running all the time, which
>> didn't require work to start or set up, which was automatically
>> started for instance by qjackctl, that you could switch to to adjust
>> volume levels. Now
>
> I'm fairly certain this is possible to rig up with some combination of jack api scripting/session management and qjackctl settings
> In my opinion, I feel I would rather not have a singular place to manage the input volumes of every port. Looking at pavucontrol already feels cluttered with a small number of devices, looking at patchmatrix with its mixers also feels cluttered, I dont like seeing every volume control at once, and would prefer them to stay attached to their respective GUIs.

Clutterered or not, this functionality is something
pulseaudio/windows/osx all provide, but not jack. Is jack better
because it doesn't provide this? No, it's worse. Granted, a properly
made mix-master client seems like a better solution, actually a much
better solution, but a mix-master client requires that all clients
autoconnect to the mix-master and not to the physical output ports.
This can of course be hacked by monitoring the clients and so forth,
but that would also be a hack that guaranteed would create
frustrations, so first of all jack needs functionalities for providing
default ports for the clients to connect to, and then all clients need
to support connecting to the default ports.


>  and I would want to at minimum adjust stereo/surround collections of ports with single controls. Which means jack would need to know these are stereo/surround collections, adding API complexity and compatibility updates. And then this calls into question issues of panning.
> Additionally
> y as someone noted, you need temp buffers per output per adjusted control. and if truly there can be no performance hit for an unadjusted control, this is perhaps not so bad, but both scenarios could put some fraction of users into maintaining their own build of jack, either to turn it on or off.

Probably not. You would need many many thousands of jack ports, or run
some kind of tiny embedded device, for the memory usage to be of any
size anyone would care about. Most people probably have no more than
around 20 custom ports + sound card ports at any time.


>>
>> you have to do all sorts of things, so instead you
>> normally just reach for alsamixer or a physical volume control if you
>
> Cant you in a lot of cases use amixer to adjust the volume for the interface? I admit I havent looked at this on my own machines.

Well, you would normally use alsamixer instead of amixer.