27 Mar
2019
27 Mar
'19
8:44 a.m.
On Wed, Mar 27, 2019 at 3:08 PM Sunset Tech <swansong.tech(a)gmail.com> wrote:
Well, you would normally use alsamixer instead of amixer.
On Wed, Mar 27, 2019, 9:18 AM Kjetil Matheussen <k.s.matheussen(a)gmail.com> wrote:
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.
On Wed, Mar 27, 2019 at 2:10 PM Sunset Tech <swansong.tech(a)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. 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.