[Jack-Devel] jackd and volume control
Locked
12
12
[Jack-Devel] jackd and volume control
 
|
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_* I'd say that 2.) will introduce too much complexity. This is what jack clients should do. But some time ago I proposed 3.) - Not every audio adapter has a software controllable hardware mixer, e.g. Focusrite Scarlett Solo, 2i2, 2i4. So alsamixer can't do the job. - No need to break clients' connection to system:playback_* and make connections to a volume control application like jack_mixer. That's really nasty when the application connects only at playback with changing port names, like Audacity. Then you need tools like jack-plumbing. I can live without that but that's what new users would appreciate, especially when there are some apps for the system tray/dock/whatever. _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
As an old JACK2 developer I would say: Fons is (almost always…) right, listen to him ((-;
Stéphane > Le 27 mars 2019 à 19:22, Holger Marzen <[hidden email]> a écrit : > > 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_* > > I'd say that 2.) will introduce too much complexity. This is what jack > clients should do. > > But some time ago I proposed 3.) > > - Not every audio adapter has a software controllable hardware mixer, > e.g. Focusrite Scarlett Solo, 2i2, 2i4. So alsamixer can't do the job. > > - No need to break clients' connection to system:playback_* and make > connections to a volume control application like jack_mixer. > That's really nasty when the application connects only at playback > with changing port names, like Audacity. Then you need tools like > jack-plumbing. > > I can live without that but that's what new users would appreciate, > especially when there are some apps for the system tray/dock/whatever. > _______________________________________________ > Jack-Devel mailing list > [hidden email] > http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
In reply to this post by Holger Marzen
On Wed, 27 Mar 2019 19:22:23 +0100 (CET), Holger Marzen wrote:
>Not every audio adapter has a software controllable hardware mixer, > e.g. Focusrite Scarlett Solo, 2i2, 2i4. So alsamixer can't do the > job. Hi, for audio I'm using a RME HDSP AIO, IOW I can use hdspmixer for the hardware routing, as well as for output level control. The ALSA driver is broken or unfinished, so it's not possible to tap the full potential of the RME card, however, I've got the possibility to change the output levels, so I can form an opinion regarding the importance. For audio I'm also using a Focusrite Scarlett 18i20 2nd Gen. I don't understand how I would benefit from output level control provided by jack, when using the Focusrite. It would be nice, if I could control the hardware routing of the Focusrite, but even this isn't essential. On my iPad Pro I'm using AUM and indeed AUM provides volume control, but AUM is comparable to a host, similar to jack-rack. It's possible to use apps without AUM, as it's possible to use Linux software without jack-rack, but then there is no extra volume control available, it's the same as for Linux. It's a long, long time ago that I used Windows, but IIRC ASIO didn't provide output level control. For Windows I had Totalmix for the RME card and some hardware mixer control for an Envy24 card, IOW what is know as hdspmixer and envy24control, resp. mudita24 in Linux. Btw. I'm surprised about how less jack ports are supposedly used by "most" people. I belong to those who use way more tracks and sub-groups than "most" people seem to use ports. Regards, Ralf -- pacman -Q linux{,-rt{-pussytoes,-securityink,-cornflower,}}|cut -d\ -f2 5.0.4.arch1-1 5.0.3_rt1-0 4.19.31_rt18-0 4.19.25_rt16-0 4.19.23_rt13-0.1 _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
In reply to this post by Holger Marzen
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. _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
Am Mi., 27. März 2019 um 20:55 Uhr schrieb Filipe Coelho <[hidden email]>:
> > 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. Now that settles that ;-) Thank you! _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
Re: jackd and volume control
|
|
In reply to this post by Holger Marzen
On Wed, Mar 27, 2019 at 7:22 PM Holger Marzen <[hidden email]> 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_* > > I'd say that 2.) will introduce too much complexity. This is what jack > clients should do. > > But some time ago I proposed 3.) > This is an old discussion. It's about default output ports. Jack doesn't provide this concept, but it should. If it had, someone would have made a mixer program by now. Now it's almost impossible to make such a program. You have to hack it together by monitoring ports, but it's not nice and probably won't work as well as it should. So that's the fourth opinion. The lack of default output ports also causes lots of clients to connect directly to system out, which may cause people to destroy their monitors. _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
Re: jackd and volume control
|
|
In reply to this post by Filipe Coelho
On Wed, Mar 27, 2019 at 8:55 PM Filipe Coelho <[hidden email]> 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. And what are your opinion about functions for providing default output ports? That would also solve the client mixer problem. _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
In reply to this post by Kjetil Matheussen-2
On Thu, 28 Mar 2019, Kjetil Matheussen wrote:
> On Wed, Mar 27, 2019 at 7:22 PM Holger Marzen <[hidden email]> 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_* > > > > I'd say that 2.) will introduce too much complexity. This is what jack > > clients should do. > > > > But some time ago I proposed 3.) > > > > This is an old discussion. It's about default output ports. Jack > doesn't provide this concept, but it should. If it had, someone would > have made a mixer program by now. Now it's almost impossible to make > such a program. You have to hack it together by monitoring ports, but > it's not nice and probably won't work as well as it should. So that's > the fourth opinion. The lack of default output ports also causes lots > of clients to connect directly to system out, which may cause people > to destroy their monitors. The problem can be solved with starting "jack_thru main" and jack-plumbing rules that disconnect clients from system:playback and connects them to main:input. It's not perfect but it works for me. A jack beginner can't. Maybe that's one of the reasons why pulseaudio won the race (and gets in the way of nearly every newbie who wants to run jack). Since I don't feel to fork jack to add a master volume and a standard monitor port I simply accept falkTX's decision and try to help other newbies to solve their problems with tools that are already available. _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
In reply to this post by Kjetil Matheussen-2
On 28.03.2019 21:27, Kjetil Matheussen wrote:
> On Wed, Mar 27, 2019 at 8:55 PM Filipe Coelho <[hidden email]> 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. 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... _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
In reply to this post by Kjetil Matheussen-2
On Thu, 28 Mar 2019, Kjetil Matheussen wrote:
> On Wed, Mar 27, 2019 at 8:55 PM Filipe Coelho <[hidden email]> 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 Lots of processing and copying data. This should be done within clients or with a mixer application. > 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 jack_mixer exist. It can be configured for as many inputs as you need and act as a fixed, always available output port where recording applications can connect. You need some help from jack-plumbing, though. > expect. And what are your opinion about functions for providing > default output ports? That would also solve the client mixer problem. I think the decision has been taken with avoiding any more complexity in jack in mind. It's ok for me. _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
Re: jackd and volume control
|
|
In reply to this post by Filipe Coelho
On Thu, Mar 28, 2019 at 9:54 PM Filipe Coelho <[hidden email]> wrote:
> > On 28.03.2019 21:27, Kjetil Matheussen wrote: > > On Wed, Mar 27, 2019 at 8:55 PM Filipe Coelho <[hidden email]> 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. _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
In reply to this post by Holger Marzen
> that it's impossible to create a client mixer for jack now
http://repo.or.cz/jack_mixer.git https://www.aelius.com/njh/jackminimix/ http://www.arnoldarts.de/jackmix/ http://non-mixer.tuxfamily.org/ HTH -- Site web : https://librazik.tuxfamily.org/ Donation : https://liberapay.com/LibraZiK/ Diaspora : https://framasphere.org/people/8c184af0c9450134f6682a0000053625 Mastodon : https://mastodon.xyz/@LibraZiK _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
Re: jackd and volume control
|
|
On Thu, Mar 28, 2019 at 10:46 PM Olivier Humbert <[hidden email]> wrote:
> > > that it's impossible to create a client mixer for jack now > > http://repo.or.cz/jack_mixer.git > https://www.aelius.com/njh/jackminimix/ > http://www.arnoldarts.de/jackmix/ > http://non-mixer.tuxfamily.org/ > Thanks for the links. However, and I guess it's a little bit too much to ask reading the whole thread (especially since it's hijacked), but if you had, you would/should have known what type of jack mixer we were talking about. _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
Re: jackd and volume control
|
|
On Thu, Mar 28, 2019 at 11:14 PM Kjetil Matheussen
<[hidden email]> wrote: > > On Thu, Mar 28, 2019 at 10:46 PM Olivier Humbert <[hidden email]> wrote: > > > > > that it's impossible to create a client mixer for jack now > > > > http://repo.or.cz/jack_mixer.git > > https://www.aelius.com/njh/jackminimix/ > > http://www.arnoldarts.de/jackmix/ > > http://non-mixer.tuxfamily.org/ > > > > Thanks for the links. However, and I guess it's a little bit too much > to ask reading the whole thread (especially since it's hijacked), but > if you had, you would/should have known what type of jack mixer we > were talking about. Thought I was replying in the "[Jack-Devel] Jack Problems" thread, but these two threads are about the same. _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
In reply to this post by Kjetil Matheussen-2
Le 2019-03-28 23:14, Kjetil Matheussen a écrit :
> On Thu, Mar 28, 2019 at 10:46 PM Olivier Humbert > <[hidden email]> wrote: >> >> > that it's impossible to create a client mixer for jack now >> >> http://repo.or.cz/jack_mixer.git >> https://www.aelius.com/njh/jackminimix/ >> http://www.arnoldarts.de/jackmix/ >> http://non-mixer.tuxfamily.org/ >> > > Thanks for the links. However, and I guess it's a little bit too much > to ask reading the whole thread (especially since it's hijacked), but > if you had, you would/should have known what type of jack mixer we > were talking about. Just 3 letters for you mate : L O L Please, keep being on the agro-defensive side, that's so much usefull to help discussions/improvements... -- Site web : https://librazik.tuxfamily.org/ Donation : https://liberapay.com/LibraZiK/ Diaspora : https://framasphere.org/people/8c184af0c9450134f6682a0000053625 Mastodon : https://mastodon.xyz/@LibraZiK _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
Re: jackd and volume control
|
|
In reply to this post by Kjetil Matheussen-2
On 28/03/19 22:27, Kjetil Matheussen wrote:
> On Thu, Mar 28, 2019 at 9:54 PM Filipe Coelho<[hidden email]> wrote: >> On 28.03.2019 21:27, Kjetil Matheussen wrote: >>> On Wed, Mar 27, 2019 at 8:55 PM Filipe Coelho<[hidden email]> 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 _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
On Thu, March 28, 2019 23:40, Tobias Hoffmann wrote:
> 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). re "insert itself into the relevant connections" I guess this could be something useful for tapping into the graph at any point. It would be ideal if inserting a tap could be assured to be single-cycle transaction without an audible effect. As an example: port a ------------> port b 1) situation at beginning tap client 2) start tap client __________ / \ 3) (port a and port b still connected) port a ->tap client port b connect port a to tap client in port a ->tap client->port b 4) connect tap client out to port b AND disconnect port a -> port b connection My question is whether this can happen without any discontinuity in the signal received on port b. Thinking about it, why not try with a small test program.. Insights are welcome. While we're at it, here's another thing related to individual gain. There is a class of jack clients that are very simplistic and often work in concert with other clients, all orchestrated by what jack has to offer. For such clients, it could be interesting to basically "request" to get a channel strip on the default mixer, and get connected there. Such client (or external tool) will indicate that via meta-data. The (exchangeable) main mixer will look for clients that want some higher level tool handle their *connection*, eg. towards an amp and become a channel on the mixer. It's a bit semantic along "i'm a testtone, please connect me as a mono input to the next best available mixer in jack". This would already be possible but semantics are missing (all meta-data stuff). It's all about connections :i) Greetings Thomas _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
In reply to this post by Stéphane Letz
On 3/27/19 7:54 PM, Stéphane Letz wrote:
> As an old JACK2 developer I would say: Fons is (almost always…) right, listen to him ((-; > > Stéphane words to live by! robin _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
Re: jackd and volume control
|
|
On 3/28/19 5:18 PM, Robin Gareus wrote:
> On 3/27/19 7:54 PM, Stéphane Letz wrote: >> As an old JACK2 developer I would say: Fons is (almost always…) right, listen to him ((-; > > words to live by! Indeed. I have learned over time to pay close attention and read carefully when some users post - Fons is one of them. To the proponents of gain control in the crosspoints of the jack matrix: please post code in the form of a patch for jack1 and jack2 that can be reviewed. Not a big deal if this is so easy to do without side effects or performance degradation in all platforms Jack supports. -- Fernando "who has not groked the source, so should shut up" _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
Re: jackd and volume control
|
|
Hi,
thanks Fernando. To all: Please, can we just close this bikeshed for good? -- Orm Am Donnerstag, den 28. März 2019 um 18:20:26 Uhr (-0700) schrieb Fernando Lopez-Lezcano: > On 3/28/19 5:18 PM, Robin Gareus wrote: > > On 3/27/19 7:54 PM, Stéphane Letz wrote: > > > As an old JACK2 developer I would say: Fons is (almost always…) right, listen to him ((-; > > > > words to live by! > > Indeed. I have learned over time to pay close attention and read carefully > when some users post - Fons is one of them. > > To the proponents of gain control in the crosspoints of the jack matrix: > please post code in the form of a patch for jack1 and jack2 that can be > reviewed. Not a big deal if this is so easy to do without side effects or > performance degradation in all platforms Jack supports. > > -- Fernando "who has not groked the source, so should shut up" > > _______________________________________________ > Jack-Devel mailing list > [hidden email] > http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
«
Return to Jackit
|
1 view|%1 views
| Free forum by Nabble | Edit this page |