27 Mar
2019
27 Mar
'19
12:22 p.m.
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.
27 Mar
27 Mar
12:54 p.m.
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
<holger(a)marzen.de> 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
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
7:20 p.m.
On 3/28/19 5:18 PM, Robin Gareus wrote:
On 3/27/19 7:54 PM, Stéphane Letz wrote:
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"
As an old JACK2 developer I would say: Fons is
(almost always…) right, listen to him ((-;
words to live by! 
29 Mar
29 Mar
3:19 a.m.
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:
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
Jack-Devel(a)lists.jackaudio.org
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 ((-;
words to live by! 
10:03 a.m.
I want to post on top and have the last word. Just because it was very
exciting to see all the good lords having their say on this list. It's
still alive!
Cheers
On Fri, March 29, 2019 10:19, Orm Finnendahl wrote:
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:
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
On 3/27/19 7:54 PM, Stéphane Letz wrote:
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
Jack-Devel(a)lists.jackaudio.org
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 ((-;
words to live by! 
1:03 p.m.
That's a positive last post Thomas. Really sorry that I couldn't
resist posting another one, but there's been some factual
misinformation in this thread, and I have a feeling that it's not been
clear that it is actually misinformation.
Port gain connections does not require extra memory, extra context
switches, or extra CPU usage (except when applying the gain itself if
connection gain is not 1.0). That's fine, we all
make mistakes, but unfortunately several people just repeated these
claims afterwards. I think those who just repeated these claims should
search within themselves and think about why they did that.
For anyone reading this later who think about maybe implementing port
gain, the only things needed to do is to extend the API, add a gain
array into the connection manager shared memory (well, this requires
some memory, but it's not much compared to what's already there), plus
modify the mixing routine. The last part seems to require a little bit
work since there's some hardware optimization you either have to try
match up in performance, or to just do a plain float vector addition,
at least as a first step. Smoothing the gain values to avoid clicks
and zipper noise would be nice too, but it's not essential as a first
step. It might be slightly more complicated than this, but I'm pretty
sure that's the essential steps.
From the discussion here, it seems unlikely that such a
modification
would be merged, but I hope we one day would move away from installing
libjack and friends into the system, but that these are instead
included with a controller program (for instance qjackctl), like I do
for Radium on Windows, i.e that all libjack functions are weak-linked
and automatically links to the libraries specified by the the
controller program (i.e the controller program specify the path of the
jack libraries). Then the controller program could include a client
mixer and a connection GUI, plus interface to start and stop the
server. This requires current clients to be recompiled though, but not
only is this way much simpler for the user, I think it may also be a
way to make jack more popular on windows and osx, and even linux. This
way, it would also be much simpler to fork jack, and include features
such as jack port connections.
I wish we could have focused more on the philosophical discussion
about what jack is and what it should be used for (and in a slightly
less hostile tone), but it's important to get the facts right.
On Fri, Mar 29, 2019 at 5:03 PM Thomas Brand <tom(a)trellis.ch> wrote:
I want to post on top and have the last word. Just because it was very
exciting to see all the good lords having their say on this list. It's
still alive!
Cheers
On Fri, March 29, 2019 10:19, Orm Finnendahl wrote:
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:
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org On 3/28/19 5:18 PM, Robin Gareus wrote:
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
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
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
10:15 p.m.
This behaviour is really not nice, you are now under moderation.
So I will review your emails before they get sent to others.
Considering I am overseas on holidays, this might take a while ;)
Use the time to take a little break from this mailing list maybe,
thanks for understanding.
On 3/29/19 8:02 PM, Kjetil Matheussen wrote:
That's a positive last post Thomas. Really sorry
that I couldn't
resist posting another one, but there's been some factual
misinformation in this thread, and I have a feeling that it's not been
clear that it is actually misinformation.
Port gain connections does not require extra memory, extra context
switches, or extra CPU usage (except when applying the gain itself if
connection gain is not 1.0). That's fine, we all
make mistakes, but unfortunately several people just repeated these
claims afterwards. I think those who just repeated these claims should
search within themselves and think about why they did that.
For anyone reading this later who think about maybe implementing port
gain, the only things needed to do is to extend the API, add a gain
array into the connection manager shared memory (well, this requires
some memory, but it's not much compared to what's already there), plus
modify the mixing routine. The last part seems to require a little bit
work since there's some hardware optimization you either have to try
match up in performance, or to just do a plain float vector addition,
at least as a first step. Smoothing the gain values to avoid clicks
and zipper noise would be nice too, but it's not essential as a first
step. It might be slightly more complicated than this, but I'm pretty
sure that's the essential steps.
From the discussion here, it seems unlikely that such a modification
would be merged, but I hope we one day would move away from installing
libjack and friends into the system, but that these are instead
included with a controller program (for instance qjackctl), like I do
for Radium on Windows, i.e that all libjack functions are weak-linked
and automatically links to the libraries specified by the the
controller program (i.e the controller program specify the path of the
jack libraries). Then the controller program could include a client
mixer and a connection GUI, plus interface to start and stop the
server. This requires current clients to be recompiled though, but not
only is this way much simpler for the user, I think it may also be a
way to make jack more popular on windows and osx, and even linux. This
way, it would also be much simpler to fork jack, and include features
such as jack port connections.
I wish we could have focused more on the philosophical discussion
about what jack is and what it should be used for (and in a slightly
less hostile tone), but it's important to get the facts right.
On Fri, Mar 29, 2019 at 5:03 PM Thomas Brand <tom(a)trellis.ch> wrote:
I want to post on top and have the last word. Just because it was very
exciting to see all the good lords having their say on this list. It's
still alive!
Cheers
On Fri, March 29, 2019 10:19, Orm Finnendahl wrote:
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org 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:
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org 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
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
30 Mar
30 Mar
3:54 a.m.
On Sat, March 30, 2019 05:15, Filipe Coelho wrote:
This behaviour is really not nice, you are now under
moderation.
So I will review your emails before they get sent to others.
Considering I am overseas on holidays, this might take a while ;)
Falktx, this seems a bit harsh - I think nobody has qualified yet to be
blocked or moderated. Please rethink your action (once you see this).
Greetings
Thomas
6:59 a.m.
On Sat, Mar 30, 2019 at 5:15 AM Filipe Coelho <falktx(a)gmail.com> wrote:
This behaviour is really not nice, you are now under moderation.
So I will review your emails before they get sent to others.
Considering I am overseas on holidays, this might take a while ;)
Use the time to take a little break from this mailing list maybe,
thanks for understanding.
Oh really? Was it because of this sentence? "This way, it would also
be much simpler to fork jack, and include features such as jack port
connections."?
27 Mar
27 Mar
1:11 p.m.
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
1:55 p.m.
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.
2:28 p.m.
On Wed, Mar 27, 2019 at 8:55 PM Filipe Coelho <falktx(a)gmail.com> wrote:
On 27.03.2019 19:22, Holger Marzen wrote:
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.
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.
2:54 p.m.
On 28.03.2019 21:27, Kjetil Matheussen wrote:
On Wed, Mar 27, 2019 at 8:55 PM Filipe Coelho
<falktx(a)gmail.com> wrote:
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.
On 27.03.2019 19:22, Holger Marzen wrote:
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. 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.
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...
3:27 p.m.
On Thu, Mar 28, 2019 at 9:54 PM Filipe Coelho <falktx(a)gmail.com> wrote:
On 28.03.2019 21:27, Kjetil Matheussen wrote:
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.
On Wed, Mar 27, 2019 at 8:55 PM Filipe Coelho
<falktx(a)gmail.com> wrote:
This has been debated to death already, you are just not willing to
listen and quickly dismiss the other side. On 27.03.2019 19:22, Holger Marzen wrote:
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. 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.
I am not adding more fuel to the fire, let's stop the discussion here
since, as I said, it will just not happen.
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.
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...
4:41 p.m.
On 28/03/19 22:27, Kjetil Matheussen wrote:
On Thu, Mar 28, 2019 at 9:54 PM Filipe
Coelho<falktx(a)gmail.com> wrote:
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
On 28.03.2019 21:27, Kjetil Matheussen wrote:
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. On Wed, Mar 27, 2019 at 8:55 PM Filipe
Coelho<falktx(a)gmail.com> wrote:
This has been debated to death already, you are just not willing to
listen and quickly dismiss the other side. 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.
6:06 p.m.
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
2:58 p.m.
On Thu, 28 Mar 2019, Kjetil Matheussen wrote:
On Wed, Mar 27, 2019 at 8:55 PM Filipe Coelho
<falktx(a)gmail.com> wrote:
Lots of processing and copying data. This should be done within clients
or with a mixer application.
On 27.03.2019 19:22, Holger Marzen wrote:
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 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.
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.
3:46 p.m.
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
4:14 p.m.
On Thu, Mar 28, 2019 at 10:46 PM Olivier Humbert <trebmuh(a)tuxfamily.org> wrote:
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.
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/
4:16 p.m.
On Thu, Mar 28, 2019 at 11:14 PM Kjetil Matheussen
<k.s.matheussen(a)gmail.com> wrote:
On Thu, Mar 28, 2019 at 10:46 PM Olivier Humbert <trebmuh(a)tuxfamily.org> wrote:
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.
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/
4:21 p.m.
Le 2019-03-28 23:14, Kjetil Matheussen a écrit :
On Thu, Mar 28, 2019 at 10:46 PM Olivier Humbert
<trebmuh(a)tuxfamily.org> wrote:
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
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/
2:22 p.m.
On Wed, Mar 27, 2019 at 7:22 PM Holger Marzen <holger(a)marzen.de> 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.
2:51 p.m.
On Thu, 28 Mar 2019, Kjetil Matheussen wrote:
On Wed, Mar 27, 2019 at 7:22 PM Holger Marzen
<holger(a)marzen.de> wrote:
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.
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.
1847
days inactive
1850
days old
jackaudio@lists.linuxaudio.org
24 comments
12 participants
participants (12)
-
Felix Homann -
Fernando Lopez-Lezcano -
Filipe Coelho -
Holger Marzen -
Kjetil Matheussen -
Olivier Humbert -
Orm Finnendahl -
Ralf Mardorf -
Robin Gareus -
Stéphane Letz -
Thomas Brand -
Tobias Hoffmann