3 Oct
2018
3 Oct
'18
2:51 p.m.
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.
3 Oct
3 Oct
3:53 p.m.
Hi!
On Wed, 3 Oct 2018 12:51:40 +0000
Dale Powell <dj_kaza(a)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
4:18 p.m.
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-bounces(a)lists.linuxaudio.org> on behalf of
Johannes Kroll <j-kroll(a)gmx.de>
Sent: 03 October 2018 13:53
To: linux-audio-user(a)lists.linuxaudio.org
Subject: Re: [LAU] Default Jack metering (XFCE QJackCTL)
Hi!
On Wed, 3 Oct 2018 12:51:40 +0000
Dale Powell <dj_kaza(a)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
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-user
4:20 p.m.
On Wed, Oct 3, 2018 at 9:53 AM Johannes Kroll <j-kroll(a)gmx.de> wrote:
Hi!
On Wed, 3 Oct 2018 12:51:40 +0000
Dale Powell <dj_kaza(a)hotmail.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.
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.
6:29 p.m.
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(a)rncbc.org
6:35 p.m.
On 10/3/18 5:29 PM, Rui Nuno Capela wrote:
On 10/3/18 3:19 PM, Paul Davis wrote:
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(a)rncbc.org
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...
6:36 p.m.
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?
7:25 p.m.
On Wed, 3 Oct 2018 10:19:40 -0400
Paul Davis <paul(a)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*?
7:27 p.m.
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
9:41 p.m.
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.
9:59 p.m.
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
10:01 p.m.
On Wed, Oct 3, 2018 at 3:41 PM Tim <termtech(a)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.
10:26 p.m.
On 10/03/2018 04:00 PM, Paul Davis wrote:
On Wed, Oct 3, 2018 at 3:41 PM Tim <termtech(a)rogers.com
<mailto:termtech@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.
10:59 p.m.
On Wed, Oct 3, 2018 at 4:26 PM Tim <termtech(a)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.
On Wed, Oct 3, 2018 at 3:41 PM Tim <termtech(a)rogers.com
<mailto:termtech@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?
11:16 p.m.
On 10/03/2018 04:58 PM, Paul Davis wrote:
On Wed, Oct 3, 2018 at 4:26 PM Tim <termtech(a)rogers.com
<mailto:termtech@rogers.com>> wrote:
On 10/03/2018 04:00 PM, Paul Davis wrote:
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.
On Wed, Oct 3, 2018 at 3:41 PM Tim <termtech(a)rogers.com
<mailto:termtech@rogers.com>
<mailto:termtech@rogers.com
<mailto:termtech@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.
4 Oct
4 Oct
12:49 a.m.
On Wed, Oct 3, 2018 at 5:16 PM Tim <termtech(a)rogers.com> wrote:
On 10/03/2018 04:58 PM, Paul Davis wrote:
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,
On Wed, Oct 3, 2018 at 4:26 PM Tim <termtech(a)rogers.com
<mailto:termtech@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.
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-user(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-user
11:42 a.m.
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-bounces(a)lists.linuxaudio.org> on behalf of
Paul Davis <paul(a)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
<termtech@rogers.com<mailto:termtech@rogers.com>> wrote:
On 10/03/2018 04:58 PM, Paul Davis wrote:
On Wed, Oct 3, 2018 at 4:26 PM Tim
<termtech@rogers.com<mailto:termtech@rogers.com>
<mailto:termtech@rogers.com<mailto:termtech@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-user@lists.linuxaudio.org<mailto:Linux-audio-user@lists.linuxaudio.org>
https://lists.linuxaudio.org/listinfo/linux-audio-user
2063
days inactive
2064
days old
linux-audio-user@lists.linuxaudio.org
16 comments
7 participants
participants (7)
-
Dale Powell -
Ede Wolf -
Johannes Kroll -
Len Ovens -
Paul Davis -
Rui Nuno Capela -
Tim