Re: jackd and volume control
Kjetil Matheussen <[email protected]> Thu, 28 Mar 2019 22:27:47 +0100
| Newsgroups | gmane.comp.audio.jackit |
|---|---|
| Message-ID | <CAC6niEJNH23vnyEGELNnpnkQm9Y6jMmkugw_KkcSNcYKH+dFww@mail.gmail.com> |
On Thu, Mar 28, 2019 at 9:54 PM Filipe Coelho <[email protected]> wrote: > > On 28.03.2019 21:27, Kjetil Matheussen wrote: > > On Wed, Mar 27, 2019 at 8:55 PM Filipe Coelho <[email protected]> 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. > > I am not adding more fuel to the fire, let's stop the discussion here > since, as I said, it will just not happen. > > > > And what are your opinion about functions for providing > > default output ports? That would also solve the client mixer problem. > > The "default" ports should be set via meta-data. > I said this before on this mailing list just a few emails back, not sure > if you noticed... > Sorry I didn't notice. I can't find the post in my mailbox either, but it's good to know that's something is happening.