27 Jan
2018
27 Jan
'18
2:03 a.m.
Hi all,
New to JACK wrt actual usage, I'm having a project which I want to setup as follows:
1. JACK in (hw:0,0) -> "JACK mixer"
(This one should be as low a latency as possible, preferably 48 frames @48 Khz, i.e.
1ms buffer size)
2. Any-app-using-ALSA -> ALSA JACK plugin -> JACK "mixer"
3. JACK "mixer" -> JACK DSP plugin -> JACK out (hw:0,0)
This will, in this particular case, run on a RPi3. Design goals are: One low latency route
between input and output on a I2S sound card (1. above) and the rest of the applications
using ALSA should share a higher latency route. The output of the JACK "mixer"
should pass a JACK plugin before reaching hw:0,0.
Before I get my hands too dirty I'd just like to ask if this architecture is feasible
to do ?
Regards
/Robert
27 Jan
27 Jan
8:53 a.m.
This is my understanding of your situation, but I have not used RPi for
audio, so if someone who has says differently weight that opinion higher
than mine.
On Sat, January 27, 2018 3:03 am, Robert Bielik wrote:
1. JACK in (hw:0,0) -> "JACK mixer"
(This one should be as low a latency as possible, preferably 48 frames
@48 Khz, i.e. 1ms buffer size)
Should be possible, but is getting down to the latency range where you
have to be careful of system configuration. You may need an RT kernel.
Some devices require power of 2 sizes, so depending on the audio interface
you may have to choose 32 or 64 rather than 48.
2. Any-app-using-ALSA -> ALSA JACK plugin ->
JACK "mixer"
I do not know if the ALSA JACK plugin allows setting higher latency for
the ALSA interface than the jackd settings. I think Paul has mentioned
that as a limitation before.
3. JACK "mixer" -> JACK DSP plugin ->
JACK out (hw:0,0)
Rather than a plugin, you will likely find it easier to develop a stand
along jack application. The jack design is not really made for having
plugins in the server.
--
Chris Caudle
11:42 a.m.
New subject: [Jack-Devel] Usage feasibility Q
On 27.01.2018 16:53, Chris Caudle wrote:
The JACK internal clients API disagrees with you ;)
Internal clients are faster to run, since they dont require context
switches between different processes.
They're harder to control externally though.
3. JACK
"mixer" -> JACK DSP plugin -> JACK out (hw:0,0)
Rather than a
plugin, you will likely find it easier to develop a stand
along jack application. The jack design is not really made for having
plugins in the server. 
1:42 p.m.
New subject: [Jack-Devel] Usage feasibility Q
On Sat, Jan 27, 2018 at 07:42:17PM +0100, Filipe Coelho wrote:
On 27.01.2018 16:53, Chris Caudle wrote:
The JACK internal clients API disagrees with you ;)
Internal clients are faster to run, since they dont require context
switches between different processes.
They're harder to control externally though.
That's a bit too simple. They will save a context switch only
if the previous or next client is internal as well.
And anyway, context switches are quite fast. I routinely run
systems with something between 15 and 20 Jack clients, the
overhead is absolutely insignificant.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
3. JACK
"mixer" -> JACK DSP plugin -> JACK out (hw:0,0)
Rather than a
plugin, you will likely find it easier to develop a stand
along jack application. The jack design is not really made for having
plugins in the server.
3:03 p.m.
New subject: [Jack-Devel] Usage feasibility Q
On 27.01.2018 21:41, Fons Adriaensen wrote:
On Sat, Jan 27, 2018 at 07:42:17PM +0100, Filipe
Coelho wrote:
Are those systems the regular 32 or 64bit intel systems?
While the hit might be no so significant there (for < 20 clients), the
same is not true for ARM-based CPUs in my experience.
When doing developing for MOD, internal vs external clients made a real
difference.
We were able to push around 30 clients (internal) instead of just 15 or
less (external).
The difference was clearly visible on the DSP load.
FYI, everything on the MOD platform runs as internal client, except for
jack capture.
On 27.01.2018 16:53, Chris Caudle wrote:
The JACK internal clients API disagrees with you ;)
Internal clients are faster to run, since they dont require context
switches between different processes.
They're harder to control externally though.
That's a bit too simple. They
will save a context switch only
if the previous or next client is internal as well.
And anyway, context switches are quite fast. I routinely run
systems with something between 15 and 20 Jack clients, the
overhead is absolutely insignificant. 3. JACK
"mixer" -> JACK DSP plugin -> JACK out (hw:0,0)
Rather than a
plugin, you will likely find it easier to develop a stand
along jack application. The jack design is not really made for having
plugins in the server.
1:56 p.m.
New subject: [Jack-Devel] Usage feasibility Q
On Sat, January 27, 2018 12:42 pm, Filipe Coelho wrote:
> The jack design is not really made for having
> plugins in the server.
The JACK internal clients API disagrees with you ;)
OK, I stated too strongly. Perhaps a better way to state is that
implementing the DSP as an external jack program may be more convenient,
and would be the more typical way to implement.
I'm not completely convinced that what I stated was actually too strong,
though.
To quote Paul Davis
https://lists.linuxaudio.org/pipermail/linux-audio-user/2018-January/109472…
"In-process JACK clients are a very special case and almost nobody
implements or uses them. They are like plugins for the JACK server, and
that's not really the point of JACK (which was designed to connect distinct
processes)."
I consider Paul a reasonably good authority on jack programming.
Internal clients are faster to run, since they dont
require context
switches between different processes.
Context switches are only a few microseconds. Whether to implement as a
plugin or external client should be based on development effort and ease
of debugging, the context switch time should be less than 0.5% of any
reasonably sized period so should not be a consideration.
They're harder to control externally though.
Which functions are implemented as jack plugins? There are several
example clients available from the jack source repository, are there
example internal plugins?
--
Chris Caudle
3:13 p.m.
New subject: [Jack-Devel] Usage feasibility Q
On 27.01.2018 21:55, Chris Caudle wrote:
I responded to these 2 on the reply from Fons.
But in short, pretty much all of the MOD software runs as internal
client (host, peak-meter, serial-midi-handler and file player).
This makes a real difference on their hardware, and was the way to go to
maximize performance.
They're hard to control because you don't have direct access to the
process running your client unless you start JACK yourself.
Typically you make your internal client listen to a known socket or
other interface, and connect there.
On the other hand, running as internal client means if your process
crashes, JACK crashes too (they're the same process).
On Sat, January 27, 2018 12:42 pm, Filipe Coelho
wrote:
OK, I stated too strongly. Perhaps a better way to state is that
implementing the DSP as an external jack program may be more convenient,
and would be the more typical way to implement.
I'm not completely convinced that what I stated was actually too strong,
though.
To quote Paul Davis
https://lists.linuxaudio.org/pipermail/linux-audio-user/2018-January/109472…
"In-process JACK clients are a very special case and almost nobody
implements or uses them. They are like plugins for the JACK server, and
that's not really the point of JACK (which was designed to connect distinct
processes)."
I consider Paul a reasonably good authority on jack programming.
Me too, and what he says is right.
JACK was made with external clients in mind, and it's what 99.9% of apps
use.
But there are specific scenarios where internal clients are useful.
The jack
design is not really made for having
plugins in the server.
The JACK internal clients API disagrees with you ;) Internal
clients are faster to run, since they dont require context
switches between different processes.
Context switches are only a few
microseconds. Whether to implement as a
plugin or external client should be based on development effort and ease
of debugging, the context switch time should be less than 0.5% of any
reasonably sized period so should not be a consideration.
They're harder to control externally though.
Which functions are implemented as jack plugins? There are several
example clients available from the jack source repository, are there
example internal plugins?
4:27 p.m.
New subject: [Jack-Devel] Usage feasibility Q
On Sat, January 27, 2018 4:13 pm, Filipe Coelho wrote:
But there are specific scenarios where internal
clients are useful.
OK, agreed, your specific case of 2x more processes running in a MOD is a
case where it is useful.
But to get back to the topic at hand, the original poster asked about
running 1 DSP client.
I still think that for that case developing as a stand alone jack
connected application on a desktop machine, then moving to the ARM SBC
when it is working reasonably well is going to be the lowest effort path.
--
Chris Caudle
28 Jan
28 Jan
1:07 a.m.
New subject: [Jack-Devel] Usage feasibility Q
But there are
specific scenarios where internal clients are useful.
OK, agreed, your specific case of 2x more processes running in a MOD is a
case where it is useful.
But to get back to the topic at hand, the original poster asked about
running 1 DSP client.
I still think that for that case developing as a stand alone jack
connected application on a desktop machine, then moving to the ARM SBC
when it is working reasonably well is going to be the lowest effort path.
2:31 a.m.
New subject: [Jack-Devel] Usage feasibility Q
Now I'll just have to get jack to work at all on
my platform (RPi3 +
Audioinjector Octocard), having trouble with dbus/X11 as I run Raspbian
Stretch headless...
Ok, speaking of which, apparently I need to use jackd2
(http://forum.audioinjector.net/viewtopic.php?f=5&t=16)=16), but I have no X11 installed,
which seems to be needed ?:
pi@AccordPi:~ $ sudo jackd -d alsa
jackdmp 1.9.11
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2014 Grame.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK server starting in realtime mode with priority 10
self-connect-mode is "Don't restrict self connect requests"
Failed to connect to session bus for device reservation /usr/bin/dbus-launch terminated
abnormally with the following error: Autolaunch error: X11 initialization failed.
Audio device hw:0 cannot be acquired...
Cannot initialize driver
JackServer::Open failed with -1
Failed to open server
Is there a way to get around this ?
Regards
/R
3:13 a.m.
New subject: [Jack-Devel] Usage feasibility Q
On 28.01.2018 10:31, Robert Bielik wrote:
It's dbus that's needed, not X.
Now I'll
just have to get jack to work at all on my platform (RPi3 +
Audioinjector Octocard), having trouble with dbus/X11 as I run Raspbian
Stretch headless...
Ok, speaking of which, apparently I need to use jackd2
(http://forum.audioinjector.net/viewtopic.php?f=5&t=16)=16), but I have no X11 installed,
which seems to be needed ?: pi@AccordPi:~ $ sudo jackd -d alsa
jackdmp 1.9.11
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2014 Grame.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK server starting in realtime mode with priority 10
self-connect-mode is "Don't restrict self connect requests"
Failed to connect to session bus for device reservation /usr/bin/dbus-launch terminated
abnormally with the following error: Autolaunch error: X11 initialization failed.
Audio device hw:0 cannot be acquired...
Cannot initialize driver
JackServer::Open failed with -1
Failed to open server
Is there a way to get around this ?
There are many, here an incomplete selection:
1. use jack1
2. recompile jack2 without dbus support
3. hack around it [1]
4. use a dummy virtual X
[1] https://linuxmusicians.com/viewtopic.php?t=12821
30 Jan
30 Jan
10:21 a.m.
New subject: [Jack-Devel] Usage feasibility Q
2. recompile jack2 without dbus support
Ok, so I've compiled/installed jack2 without dbus support, and I'm now running
jackd on a RT patched Raspbian Stretch (https://github.com/guysoft/RealtimePi)
And it seems to work wonderfully, no problem reaching buffer sizes below 1 ms. Happy joy!
I start jack with:
sudo jackd -P70 -d alsa -r 48000 -p 64 &
sudo jack_wait --wait --timeout 10
sudo jack_connect system:capture_1 system:playback_1
sudo jack_connect system:capture_2 system:playback_2
I need sudo, otherwise allocation of shared memory + realtime prio setting fails.
And then I've setup the ALSA JACK PCM plugin, but to use aplay I need to use sudo
aswell:
sudo aplay -D pcm.jack /usr/share/sounds/alsa/Front_Center.wav
Is there a way to set this up so sudo is not needed?
Regards
/R
10:35 a.m.
New subject: [Jack-Devel] RME RayDAT?
I need to replace my RME DigiFace which met an unfortunate end
recently. Is anyone on this list using the RayDAT card? If so, how is
it? In particular, does S/MUX work properly, and what kind of latencies
are you able to get?
Thanks,
David Nielson
10:39 a.m.
New subject: [Jack-Devel] Usage feasibility Q
Hi Robert,
On 30.01.2018 18:21, Robert Bielik wrote:
Make sure, that the user which starts jackd is allowed to raise the real
time priority and memlock address space.
See http://jackaudio.org/faq/linux_rt_config.html
Most distributions ship and install a limits.conf snipped file with the
jack package. Here is an example from CentOS/Fedora:
cat /etc/security/limits.d/95-jack.conf
# Default limits for users of jack-audio-connection-kit
@jackuser - rtprio 70
@jackuser - memlock 4194304
In this case, the user has to be in the @jackuser group to be able to
raise the priority.
2. recompile
jack2 without dbus support
Ok, so I've compiled/installed jack2 without dbus support, and I'm now running
jackd on a RT patched Raspbian Stretch (https://github.com/guysoft/RealtimePi)
And it seems to work wonderfully, no problem reaching buffer sizes below 1 ms. Happy
joy!
I start jack with:
sudo jackd -P70 -d alsa -r 48000 -p 64 &
sudo jack_wait --wait --timeout 10
sudo jack_connect system:capture_1 system:playback_1
sudo jack_connect system:capture_2 system:playback_2
I need sudo, otherwise allocation of shared memory + realtime prio setting fails. And then I've setup the ALSA JACK PCM plugin, but
to use aplay I need to use sudo aswell:
sudo aplay -D pcm.jack /usr/share/sounds/alsa/Front_Center.wav>
Is there a way to set this up so sudo is not needed?
What error message do you get without sudo? Maybe your user has to be in
the "audio" group (or similar).
Regards,
Chris
10:45 a.m.
New subject: [Jack-Devel] Usage feasibility Q
Make sure, that the user which starts jackd is allowed
to raise the real
time priority and memlock address space.
...
In this case, the user has to be in the @jackuser group to be able to
raise the priority.
Thanks, I thought it would something like that, Ok I'll have to figure out how to do
it on Raspbian.
What error message do you get without sudo? Maybe your
user has to be in
the "audio" group (or similar).
The error is:
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
aplay: main:788: audio open error: No such file or directory
And the "pi" user seems to be in audio group:
groups
pi adm dialout cdrom sudo audio video plugdev games users input netdev gpio i2c
spi
Running with sudo plays audio just fine.
Regards,
/Robert
10:55 a.m.
New subject: [Jack-Devel] Usage feasibility Q
On 30.01.2018 18:45, Robert Bielik wrote:
Just run aplay under the same user which already owns the jackd process.
I'm unaware about the current situation in regard of multi-user
connection support for jackd.
Best,
Chris
What error
message do you get without sudo? Maybe your user has to be in
the "audio" group (or similar).
The error is:
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
aplay: main:788: audio open error: No such file or directory
And the "pi" user seems to be in audio group:
groups
pi adm dialout cdrom sudo audio
video plugdev games users input netdev gpio i2c spi
Running with sudo plays audio just fine.
12:13 p.m.
New subject: [Jack-Devel] Usage feasibility Q
On Tue, January 30, 2018 11:45 am, Robert Bielik wrote:
Thanks, I thought it would something like that, Ok
I'll have to figure out
how to do it on Raspbian.
I am running stock debian stable on a BeagleBone Black and it has a
/etc/security/limits.conf file, but all entries are commented by default.
Perhaps you just need to add the settings described in the RT tuning FAQ
to your limits.conf file for the pi user account.
--
Chris Caudle
31 Jan
31 Jan
8:20 a.m.
New subject: [Jack-Devel] Usage feasibility Q
On 01/30/2018 08:13 PM, Chris Caudle wrote:
On Tue, January 30, 2018 11:45 am, Robert Bielik
wrote:
debian asks when installing jack (unless you install it
non-interactively). You can later change it:
sudo dpkg-reconfigure -p high jackd2
say "yes, enable realtime priority" which will update
/etc/security/limits.d/audio.conf , then re-login.
ciao,
robin
Thanks, I thought it would something like that,
Ok I'll have to figure out
how to do it on Raspbian.
I am running stock debian 
30 Jan
30 Jan
10:58 a.m.
New subject: [Jack-Devel] ?==?utf-8?q? Usage feasibility Q
Am Dienstag, 30. Januar 2018 18:38 CET, Christian Affolter
<c.affolter(a)purplehaze.ch> schrieb:
Hi Robert,
On 30.01.2018 18:21, Robert Bielik wrote:
Make sure, that the user which starts jackd is allowed to raise the real
time priority and memlock address space.
See http://jackaudio.org/faq/linux_rt_config.html
Most distributions ship and install a limits.conf snipped file with the
jack package. Here is an example from CentOS/Fedora:
cat /etc/security/limits.d/95-jack.conf
# Default limits for users of jack-audio-connection-kit
@jackuser - rtprio 70
@jackuser - memlock 4194304
In this case, the user has to be in the @jackuser group to be able to
raise the priority.
One important caveat: an often missed bit of information when this configutation is
mentioned is the
fact that this configures the pam_limits PAM module. So: pam needs to be enabled and
configured (most
if not all distros do this) and whatever process need these setting needs to gothrough a
pam session
or inherit/fork of a process that does. A "normal" login will usually do so but
some process started during
bootup or chron or directly started from init/systemd will not. You've been warned
;-)
Cheers, RalfD
2.
recompile jack2 without dbus support
Ok, so I've compiled/installed jack2 without dbus support, and I'm now running
jackd on a RT patched Raspbian Stretch (https://github.com/guysoft/RealtimePi)
And it seems to work wonderfully, no problem reaching buffer sizes below 1 ms. Happy
joy!
I start jack with:
sudo jackd -P70 -d alsa -r 48000 -p 64 &
sudo jack_wait --wait --timeout 10
sudo jack_connect system:capture_1 system:playback_1
sudo jack_connect system:capture_2 system:playback_2
I need sudo, otherwise allocation of shared memory + realtime prio setting fails. And then I've setup the ALSA JACK PCM plugin,
but to use aplay I need to use sudo aswell:
sudo aplay -D pcm.jack /usr/share/sounds/alsa/Front_Center.wav>
Is there a way to set this up so sudo is not needed?
What error message do you get without sudo? Maybe your user has to be in
the "audio" group (or similar).
Regards,
Chris
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
27 Jan
27 Jan
3:34 p.m.
New subject: [Jack-Devel] Usage feasibility Q
On 01/27/2018 09:55 PM, Chris Caudle wrote:
Context switches are only a few microseconds.
Certainly the right ballpark, but it depends. It could easily be a few
hundred microseconds (depending on the memory touched, the architecture,
cache layout, and CPU speed). sample-players can have a rather large
working-set for example.
You can measure it:
https://github.com/tsuna/contextswitch/blob/master/timectxswws.c
ciao,
robin
4:24 p.m.
New subject: [Jack-Devel] Usage feasibility Q
On Sat, January 27, 2018 4:34 pm, Robin Gareus wrote:
On 01/27/2018 09:55 PM, Chris Caudle wrote:
OK, then "few microseconds" would be the lower bound.
I just ran that benchmark you pointed out, and on this circa 5 year old
x86 processor context switches between processes are 8 microseconds
without CPU affinity, 5 microseconds with CPU affinity. I'm not going to
worry about it for most things I deal with.
--
Chris Caudle
Context switches are only a few microseconds.
Certainly the right ballpark, but it depends. It could easily be a few
hundred microseconds
2419
days inactive
2423
days old
jackaudio@lists.linuxaudio.org
20 comments
9 participants
participants (9)
-
Chris Caudle -
Christian Affolter -
David Nielson -
Filipe Coelho -
Fons Adriaensen -
Hanspeter Portner -
Ralf Mattes -
Robert Bielik -
Robin Gareus