[LAU] Default Jack metering (XFCE QJackCTL)

[Dale Powell]

Hi all.

This question is two parts I think really. Hopefully you can help but wondering if anybody uses anything to have a metering app always across their main output. I've been looking at zita-mu1 and which not perfect (I'll go into why later) it could be a contender for this use.

But my session configurations change all the time. I use QJackCTL to start Jack and pretty much everything autoconnects to the main two Jack outputs as expected. How would I change it so that instead of connecting to the System outputs to the audio interface they connect to the input of the MU1? Or is there another way to get it in the permanent signal path between Jack's System outputs and the physical audio interface?

What I find less than ideal about the MU1 is that it is a standard application with only a application window. Is the any Jack capable metering with a Widget for XFCE (either its own widget or works with Notification Area, not with the Indicator Plugin.) Something that will give little VU/PPM bars for left and right channels up on my toolbar and allow the main window to be closed.

Hoping one of you has wanted to solve the same desire.

Dale.

[Johannes Kroll]

Hi!

On Wed, 3 Oct 2018 12:51:40 +0000
Dale Powell <***@hotmail.com> wrote:

> But my session configurations change all the time. I use QJackCTL to start Jack and pretty much everything autoconnects to the main two Jack outputs as expected. How would I change it so that instead of connecting to the System outputs to the audio interface they connect to the input of the MU1? Or is there another way to get it in the permanent signal path between Jack's System outputs and the physical audio interface?

if you enable Hardware Monitoring in Jack, you should get monitor_*
ports. You can use them to read whatever is sent to the hardware
outputs.

There are several db meters in the KXStudio repos, but I don't know of
one that works in the notification or indicator area.

Best,
Johannes

[Dale Powell]

Johannes.

Thanks for the response.

I found the option you mean, it is just Monitor rather than H/W Monitor (which I assume would try and set some internal mixer DSP modes of the interface for direct monitoring of inputs.) This is at least one step closer as this I can set up with the Persistent Patchbay to always connect.

Is there no way to have it in the chain before the System output? I would have thought having a plugin host (eg Carla) with a range of basic effects (Compressor, Limiter, EQ, Stereo and Metering) on the permanent output chain might be something people on this list would do. So when changing between studio speakers, headphone and portable speakers you might have different settings for each, or different setting for when say streaming (how many video on Youtube have the audio at the same level) and doing audio production (for examples.) I was thinking more as a basic solution along these lines which I may expand in future. Would this be maybe accomplished with clever editing of Alsa configs (asound.rc etc)?

But thank you for giving me an immediately usable solution for the specific issue I asked about.

Kind regards, Dale.

________________________________
From: Linux-audio-user <linux-audio-user-***@lists.linuxaudio.org> on behalf of Johannes Kroll <j-***@gmx.de>
Sent: 03 October 2018 13:53
To: linux-audio-***@lists.linuxaudio.org
Subject: Re: [LAU] Default Jack metering (XFCE QJackCTL)

Hi!

On Wed, 3 Oct 2018 12:51:40 +0000
Dale Powell <***@hotmail.com> wrote:

> But my session configurations change all the time. I use QJackCTL to start Jack and pretty much everything autoconnects to the main two Jack outputs as expected. How would I change it so that instead of connecting to the System outputs to the audio interface they connect to the input of the MU1? Or is there another way to get it in the permanent signal path between Jack's System outputs and the physical audio interface?

if you enable Hardware Monitoring in Jack, you should get monitor_*
ports. You can use them to read whatever is sent to the hardware
outputs.

There are several db meters in the KXStudio repos, but I don't know of
one that works in the notification or indicator area.

Best,
Johannes

[Paul Davis]

On Wed, Oct 3, 2018 at 9:53 AM Johannes Kroll <j-***@gmx.de> wrote:

> Hi!
>
> On Wed, 3 Oct 2018 12:51:40 +0000
> Dale Powell <***@hotmail.com> wrote:
>
> > But my session configurations change all the time. I use QJackCTL to
> start Jack and pretty much everything autoconnects to the main two Jack
> outputs as expected. How would I change it so that instead of connecting to
> the System outputs to the audio interface they connect to the input of the
> MU1? Or is there another way to get it in the permanent signal path between
> Jack's System outputs and the physical audio interface?
>
> if you enable Hardware Monitoring in Jack, you should get monitor_*
> ports. You can use them to read whatever is sent to the hardware
> outputs.
>

hardware monitoring in JACK is not related to the presence of the monitor_*
ports. The former is indicated by --hwmon or -H, the latter by --monitor
or -m

In addition, almost nobody should ever enable hardware monitoring in JACK.
It works on 2 kinds of (old) audio hardware, and is essentially useless
anyway.

[Rui Nuno Capela]

On 10/3/18 3:19 PM, Paul Davis wrote:
>
> hardware monitoring in JACK is not related to the presence of the
> monitor_* ports.  The former is indicated by --hwmon or -H, the latter
> by --monitor or -m
>
> In addition, almost nobody should ever enable hardware monitoring in
> JACK. It works on 2 kinds of (old) audio hardware, and is essentially
> useless anyway.
>

hi Paul,

now that you say and probably said eons ago, i'll get rid of that
useless "H/W Meters" on QjackCtl from this moment on...

cheers
--
rncbc aka. Rui Nuno Capela
***@rncbc.org

[Rui Nuno Capela]

On 10/3/18 5:29 PM, Rui Nuno Capela wrote:
> On 10/3/18 3:19 PM, Paul Davis wrote:
>>
>> hardware monitoring in JACK is not related to the presence of the
>> monitor_* ports.  The former is indicated by --hwmon or -H, the latter
>> by --monitor or -m
>>
>> In addition, almost nobody should ever enable hardware monitoring in
>> JACK. It works on 2 kinds of (old) audio hardware, and is essentially
>> useless anyway.
>>
>
> hi Paul,
>
> now that you say and probably said eons ago, i'll get rid of that
> useless "H/W Meters" on QjackCtl from this moment on...
>

sorry, my mistake or confusion: i mean "H/W Monitor" option is about to
go away for good from the QjackCtl > Setup > Settings > Advanced tab.

"H/W Meter" will stay.

byee.
--
rncbc aka. Rui Nuno Capela
***@rncbc.org

[Ede Wolf]

> hardware monitoring in JACK is not related to the presence of the
> monitor_* ports.  The former is indicated by --hwmon or -H, the latter
> by --monitor or -m


No trying to be smart, just to avoid confusion: Is it instead -M or
--hwmeter? Cannot find -m in the alsa section and in the global section
it is equal to --no-mlock. Unless I am misreading the jackd manpage.


> In addition, almost nobody should ever enable hardware monitoring in
> JACK. It works on 2 kinds of (old) audio hardware, and is essentially
> useless anyway.
>

Out of curiositiy and since I am using old hardware: Care to mention,
which two cards that are?

[Johannes Kroll]

On Wed, 3 Oct 2018 10:19:40 -0400
Paul Davis <***@linuxaudiosystems.com> wrote:

> hardware monitoring in JACK is not related to the presence of the monitor_*
> ports. The former is indicated by --hwmon or -H, the latter by --monitor
> or -m
>
> In addition, almost nobody should ever enable hardware monitoring in JACK.
> It works on 2 kinds of (old) audio hardware, and is essentially useless
> anyway.

You're right, I just assumed the Hardware Monitoring setting in Claudia
was related to the monitor_* ports. In fact, I get the monitor_* ports
regardless of the Monitoring and Metering settings.

Which makes me wonder: What do these options actually *do*?

[Len Ovens]

On Wed, 3 Oct 2018, Dale Powell wrote:

> But my session configurations change all the time. I use QJackCTL to start Jack
> and pretty much everything autoconnects to the main two Jack outputs as expected.

And therein lies your problem. "Everything auto connects" to system_1/2.
While this is a reasonable guess, it is just a guess and often wrong as
many audio IF have different ports for headphones, monitoring and main out
as well as digital (s/pdif). So auto connect works for a bunch of people
but is wrong for everyone else.

> How would I change it so that instead of connecting to the System outputs to the
> audio interface they connect to the input of the MU1? Or is there another way to
> get it in the permanent signal path between Jack's System outputs and the
> physical audio interface?

Auto connect is not a part of jackd or it's specification. It is done by
each application that chooses to do so. Some of them may choose to allow
you to auto connect to another set of ports besides system_1/2 (I don't
know of any off hand). However, the main problem with trying to have
applications auto connect to anything other than system_1/2 is that
anything else may not exist when jackd is started. So while things like
Ardour will reconnect to whatever it was connected to the last time it was
run, if what it was connected to last time is not yet started, that
connection will not happen. A workaround that is still maybe not finished
yet, is to run your jack application inside of Carla as a plugin. But
jackd itself does not come with such infrastructure.

> with only a application window. Is the any Jack capable metering with a Widget
> for XFCE (either its own widget or works with Notification Area, not with the
> Indicator Plugin.) Something that will give little VU/PPM bars for left and right
> channels up on my toolbar and allow the main window to be closed.

Not that I have seen. The systray, indicator, notification area stuff
seems to have been a moving target and getting stuff to work right with it
has not been easy. Notification in xfce openes it's own floating window
which may not be where you want it anyway. I would think a real window
that you can put where you have space would be a better deal.

meterbridge -t dpm system:playback_1 system:playback_2

takes everything connected to playback_1/2 and reroutes them through the
meter. However, anything started after meterbridge still connects to
system:playback_1/2

--
Len Ovens
www.ovenwerks.net

[Tim]

On 10/03/2018 01:26 PM, Len Ovens wrote:
> Auto connect is not a part of jackd or it's specification. It is done by
> each application that chooses to do so. Some of them may choose to allow
> you to auto connect to another set of ports besides system_1/2 (I don't
> know of any off hand). However, the main problem with trying to have
> applications auto connect to anything other than system_1/2 is that
> anything else may not exist when jackd is started. So while things like
> Ardour will reconnect to whatever it was connected to the last time it
> was run, if what it was connected to last time is not yet started, that
> connection will not happen. A workaround that is still maybe not
> finished yet, is to run your jack application inside of Carla as a
> plugin. But jackd itself does not come with such infrastructure.


Hi, just a side note. I'm not sure how other apps handle this
situation, but in MusE I have programmed it to remember
those connections.
They are preserved so that the next time they re-appear,
the song finds them. You NEVER lose them unless you
specifically tell MusE to purge them.

This was crucial for Jack midi USB devices for example.
If you unplug and re-plug a USB midi device, its ports get
new 'canonical' system names (system_3, _4 etc).
This makes it impossible to use those names to remember them.
So instead I take the first or second 'alias' port names,
which do NOT change, so it ALWAYS finds the connections,
even after re-plugging.

That is why port aliases are SO VERY important and should
never be removed from Jack.

At the time, I found this behaviour lacking in any
session manager, it also appeared to me impossible for
a session manger to even accomplish this - to know
which port was supposed to be which port the app wanted.
Thus the feature is tightly integrated in MusE,
and so very dependent on those port alias names.
Maybe things have changed with session managers over
the last several years ?

I am planning to extend that behaviour for missing
audio plugins and so on.
Credo: Nothing ever 'lost' unless the user says so.

Cheers.
Tim.

[Len Ovens]

On Wed, 3 Oct 2018, Tim wrote:

> Hi, just a side note. I'm not sure how other apps handle this
> situation, but in MusE I have programmed it to remember
> those connections.
> They are preserved so that the next time they re-appear,
> the song finds them. You NEVER lose them unless you
> specifically tell MusE to purge them.

Nice. But the application does the work, not jack. I would certainly like
to know all jack applications did that, but they don't. Some of them,
while still quite useful, are not actively maintained.

I suppose it would be possible to create a jack backend that entertained
LV2 plugins (alsa-lv2 or something). I don't know that there is interest
in the development community to do so though. (this is not the first user
to request something that works this way) I also don't know if it is a
"good idea".

--
Len Ovens
www.ovenwerks.net

[Paul Davis]

On Wed, Oct 3, 2018 at 3:41 PM Tim <***@rogers.com> wrote:

>
>
>
>
>
> That is why port aliases are SO VERY important and should
> never be removed from Jack.
>

port aliases are an ad-hoc hack.

the correct solution was added to jack1, but never (AFAIK) to jack2, and
that's metadata, along with well-known metadata keys such as "pretty-name".

port aliases should go away, and be replaced by metadata.

[Tim]

On 10/03/2018 04:00 PM, Paul Davis wrote:
>
>
> On Wed, Oct 3, 2018 at 3:41 PM Tim <***@rogers.com
> <mailto:***@rogers.com>> wrote:
>
> That is why port aliases are SO VERY important and should
>   never be removed from Jack.
>
>
> port aliases are an ad-hoc hack.
>
> the correct solution was added to jack1, but never (AFAIK) to jack2, and
> that's metadata, along with well-known metadata keys such as "pretty-name".
>
> port aliases should go away, and be replaced by metadata.
>

But when you and I last spoke of this, I was disappointed to learn
that there were no plans to put default information in that meta-data,
like the information that is provided in those alias names.
So as I understood, the meta-data would be blank by default.
You demonstrated that meta-data does work - but you had to provide
that information from your own list.

Am I mistaken? Would such information be available by default?

Thanks.
Tim.

[Paul Davis]

On Wed, Oct 3, 2018 at 4:26 PM Tim <***@rogers.com> wrote:

>
>
> On 10/03/2018 04:00 PM, Paul Davis wrote:
> >
> >
> > On Wed, Oct 3, 2018 at 3:41 PM Tim <***@rogers.com
> > <mailto:***@rogers.com>> wrote:
> >
> > That is why port aliases are SO VERY important and should
> > never be removed from Jack.
> >
> >
> > port aliases are an ad-hoc hack.
> >
> > the correct solution was added to jack1, but never (AFAIK) to jack2, and
> > that's metadata, along with well-known metadata keys such as
> "pretty-name".
> >
> > port aliases should go away, and be replaced by metadata.
> >
>
> But when you and I last spoke of this, I was disappointed to learn
> that there were no plans to put default information in that meta-data,
> like the information that is provided in those alias names.
> So as I understood, the meta-data would be blank by default.
> You demonstrated that meta-data does work - but you had to provide
> that information from your own list.
>
> Am I mistaken? Would such information be available by default?
>

In Jack1 when I left it, the server doesn't create any metadata. But
there's no hard policy on that, and technically the ALSA driver itself is
in the best position to get information from hardware to set up
"pretty-name".

Port aliases also have no official policy either.

[Tim]

On 10/03/2018 04:58 PM, Paul Davis wrote:
>
>
> On Wed, Oct 3, 2018 at 4:26 PM Tim <***@rogers.com
> <mailto:***@rogers.com>> wrote:
>
>
>
> On 10/03/2018 04:00 PM, Paul Davis wrote:
> >
> >
> > On Wed, Oct 3, 2018 at 3:41 PM Tim <***@rogers.com
> <mailto:***@rogers.com>
> > <mailto:***@rogers.com <mailto:***@rogers.com>>> wrote:
> >
> >     That is why port aliases are SO VERY important and should
> >        never be removed from Jack.
> >
> >
> > port aliases are an ad-hoc hack.
> >
> > the correct solution was added to jack1, but never (AFAIK) to
> jack2, and
> > that's metadata, along with well-known metadata keys such as
> "pretty-name".
> >
> > port aliases should go away, and be replaced by metadata.
> >
>
> But when you and I last spoke of this, I was disappointed to learn
>   that there were no plans to put default information in that
> meta-data,
>   like the information that is provided in those alias names.
> So as I understood, the meta-data would be blank by default.
> You demonstrated that meta-data does work - but you had to provide
>   that information from your own list.
>
> Am I mistaken? Would such information be available by default?
>
>
> In Jack1 when I left it, the server doesn't create any metadata. But
> there's no hard policy on that, and technically the ALSA driver itself
> is in the best position to get information from hardware to set up
> "pretty-name".
>
> Port aliases also have no official policy either.
>

Thanks Paul. Yes I suspected it might be a relatively basic step
to have something fill in that data. That would be awesome.
Hopefully it could be done if it's ever finished in Jack-1 and 2.

For Jack-2 I believe the meta-data support is currently just stubs,
as sletz has said. It appears in the headers but that's about it.
I think...

Tim.

[Paul Davis]

On Wed, Oct 3, 2018 at 5:16 PM Tim <***@rogers.com> wrote:

>
>
> On 10/03/2018 04:58 PM, Paul Davis wrote:
> >
> >
> > On Wed, Oct 3, 2018 at 4:26 PM Tim <***@rogers.com
> > <mailto:***@rogers.com>> wrote:
> >
> >
> >
> > On 10/03/2018 04:00 PM, Paul Davis wrote:
> >
> > In Jack1 when I left it, the server doesn't create any metadata. But
> > there's no hard policy on that, and technically the ALSA driver itself
> > is in the best position to get information from hardware to set up
> > "pretty-name".
> >
> > Port aliases also have no official policy either.
> >
>
> Thanks Paul. Yes I suspected it might be a relatively basic step
> to have something fill in that data. That would be awesome.
> Hopefully it could be done if it's ever finished in Jack-1 and 2.
>
>
the thing is, many times the user is in a better place than the software to
name the ports. that's why i trended toward a JACK startup process where
the user would supply the information that would get pushed into the port
metadata.

there's no way the driver knows that system:capture_1 is "kawaii k5000
left", but i do.

For Jack-2 I believe the meta-data support is currently just stubs,
> as sletz has said. It appears in the headers but that's about it.
> I think...
>

last i heard, falktx is now maintaining both jack1 and jack2.






>
> Tim.
> _______________________________________________
> Linux-audio-user mailing list
> Linux-audio-***@lists.linuxaudio.org
> https://lists.linuxaudio.org/listinfo/linux-audio-user
>

[Dale Powell]

Thanks all. Interesting discussion, even if it has slipped a little off-topic.

I was just wondering, with it being the application which auto-connect, could you make a dummy Alsa device, join it with the device in use with zita-a2j-bridge and have this as the default System-1/2 ports which everything will auto-connect to, then use a Monitor output of this to feed a DSP chain/rack which is connected to the real outputs (which can be done easily with the Persistent Patchbay.)

Would much of a performance hit be expected it this method was used? Any possible clock issues (as I guess a dummy device can't really be clocked I guess not.) What would the additional latency be (a full Jack round-trip added)??

Thanks again, Dale.


________________________________
From: Linux-audio-user <linux-audio-user-***@lists.linuxaudio.org> on behalf of Paul Davis <***@linuxaudiosystems.com>
Sent: 03 October 2018 22:49
To: Tim E. Real
Cc: linux-audio-user
Subject: Re: [LAU] Default Jack metering (XFCE QJackCTL)



On Wed, Oct 3, 2018 at 5:16 PM Tim <***@rogers.com<mailto:***@rogers.com>> wrote:


On 10/03/2018 04:58 PM, Paul Davis wrote:
>
>
> On Wed, Oct 3, 2018 at 4:26 PM Tim <***@rogers.com<mailto:***@rogers.com>
> <mailto:***@rogers.com<mailto:***@rogers.com>>> wrote:
>
>
>
> On 10/03/2018 04:00 PM, Paul Davis wrote:
>
> In Jack1 when I left it, the server doesn't create any metadata. But
> there's no hard policy on that, and technically the ALSA driver itself
> is in the best position to get information from hardware to set up
> "pretty-name".
>
> Port aliases also have no official policy either.
>

Thanks Paul. Yes I suspected it might be a relatively basic step
to have something fill in that data. That would be awesome.
Hopefully it could be done if it's ever finished in Jack-1 and 2.


the thing is, many times the user is in a better place than the software to name the ports. that's why i trended toward a JACK startup process where the user would supply the information that would get pushed into the port metadata.

there's no way the driver knows that system:capture_1 is "kawaii k5000 left", but i do.

For Jack-2 I believe the meta-data support is currently just stubs,
as sletz has said. It appears in the headers but that's about it.
I think...

last i heard, falktx is now maintaining both jack1 and jack2.






Tim.