[Jack-Devel] Usage feasibility Q

classic Classic list List threaded Threaded
60 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[Jack-Devel] Usage feasibility Q

Robert Bielik
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


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Usage feasibility Q

Chris Caudle
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


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Usage feasibility Q

Filipe Coelho
On 27.01.2018 16:53, Chris Caudle wrote:
>> 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.

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.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Usage feasibility Q

Fons Adriaensen-3
On Sat, Jan 27, 2018 at 07:42:17PM +0100, Filipe Coelho wrote:

> On 27.01.2018 16:53, Chris Caudle wrote:
> >>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.
>
> 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)

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Usage feasibility Q

Chris Caudle
In reply to this post by Filipe Coelho
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.html
"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


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Usage feasibility Q

Filipe Coelho
In reply to this post by Fons Adriaensen-3
On 27.01.2018 21:41, Fons Adriaensen wrote:

> On Sat, Jan 27, 2018 at 07:42:17PM +0100, Filipe Coelho wrote:
>> On 27.01.2018 16:53, Chris Caudle wrote:
>>>> 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.
>> 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.

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.


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Usage feasibility Q

Filipe Coelho
In reply to this post by Chris Caudle
On 27.01.2018 21:55, Chris Caudle wrote:

> 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.html
> "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.


>> 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?

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).

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Usage feasibility Q

Robin Gareus
In reply to this post by Chris Caudle
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
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Usage feasibility Q

Chris Caudle
On Sat, January 27, 2018 4:34 pm, Robin Gareus wrote:
> 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

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




_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Usage feasibility Q

Chris Caudle
In reply to this post by Filipe Coelho
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


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Usage feasibility Q

Robert Bielik
> > 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.

Thank you all for very interesting input, I'll do the DSP in a "regular" jack client to get everything working, and maybe migrate to an internal one later on, if needed.

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...

Thank you all again!
Regards
/Robert

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Usage feasibility Q

Robert Bielik
> 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), 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

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Usage feasibility Q

Hanspeter Portner-2
On 28.01.2018 10:31, Robert Bielik wrote:
>> 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), but I have no X11 installed, which seems to be needed ?:

It's dbus that's needed, not X.

> 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
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Usage feasibility Q

Robert Bielik
> 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



_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

[Jack-Devel] RME RayDAT?

David Nielson-2
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
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Usage feasibility Q

Christian Affolter
In reply to this post by Robert Bielik
Hi Robert,

On 30.01.2018 18:21, Robert Bielik wrote:

>> 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.

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.



> 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
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Usage feasibility Q

Robert Bielik
> 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
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Usage feasibility Q

Christian Affolter
On 30.01.2018 18:45, Robert Bielik wrote:

>> 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.

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
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: ?==?utf-8?q? Usage feasibility Q

Ralf Mattes
In reply to this post by Christian Affolter
 
Am Dienstag, 30. Januar 2018 18:38 CET, Christian Affolter <[hidden email]> schrieb:
 

> Hi Robert,
>
> On 30.01.2018 18:21, Robert Bielik wrote:
> >> 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.
>
> 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

>
> > 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
> [hidden email]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
 
 
 
 


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Usage feasibility Q

Chris Caudle
In reply to this post by Robert Bielik
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


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
123