[linux-audio-user] Which kernel for low latency and kernel 2.6.1-mm# problems

Robert Jonsson robert.jonsson at dataductus.se
Wed Jan 21 17:48:12 EST 2004


Hi,

onsdagen den 21 januari 2004 23.05 skrev Glenn McCord:
> Andrew Morton wrote:
> >Could someone give me a really simple description of how to obtain Jack,
> >and how to get it going sufficiently to demonstrate these problems?
> >
> >Thanks.
>
> Go to |/usr/src/linux/include/linux| (or wherever you have your kernel
> sources) and in the file |capability.h| change the line
>
> #define CAP_INIT_EFF_SET    to_cap_t(~0&~CAP_TO_MASK(CAP_SETPCAP)
> to
> #define CAP_INIT_EFF_SET    to_cap_t( ~0 )
> and the line
> #define CAP_INIT_INH_SET    to_cap_t(0)
> to
> #define CAP_INIT_INH_SET    to_cap_t( ~0 )
>
> Also make sure CONFIG_TMPFS is turned on.
>
> You must then recompile your kernel.
>
> put this in /etc/fstab (you may have to ceate the folders)
> shmfs    /dev/shm  shm     defaults 0 0|
> none /tmp/jack tmpfs defaults 0 0
>
> ||none /mnt/ramfs tmpfs defaults 0 0|
>
> Get jack at http://jackit.sourceforge.net/
> do a ./configure --with-default-tmpdir=/mnt/ramfs --enable-capabilities
> make
> make install

I believe that the kernel change can be omitted if you run the app as root. 
The --enable-capabilities can also be omitted in that case.

The tmpfs usage could call for some explanation: 
jack uses the filesystem to store ipc pipes. It was discovered that accessing 
these was the cause of xruns under kernel 2.4. 
Thus it has been common to place these pipes on a tmpfs filesystem whereas the 
xrun problem would not appear. I commonly have all of /tmp as tmpfs (then 
jack doesn't need any special compilation flags).
I imagine this is a quite uncommon usage of tmpfs, maybe that's where the 
problem lies with 2.6?


>
> http://jackit.sourceforge.net/docs/faq.php is a good explanation of
> everything anyway..
>
> I start jack as a user with
> $jackstart -R -v -d alsa -d hw:0
> but if the compatability.h wasn't altered then you can start jack as
> root with
> #jackd -R -v -d alsa -d hw:0

Though not mandatory but jack gets a bit more stressed if we connect clients 
to it. I'll try an explanation for how to get a simple setup going.
With jack there are a few simple clients. I propose connecting jack_metro.
with:
$ jack_metro -b 100
and then connect it to the jack soundcard output with:
$ jack_connect metro:100_bpm alsa_pcm:playback_1

this should result in a beeping sound at regular intervals. (extremely 
annoying stuff)
In theory that should be enough to provoke the problems... Someone that has a 
running kernel that actually is observing the problems, Glenn?, should try 
this client-setup out and see if the problems occur with _it_ too. 

>
> There's an explanation of commnad line options at
> http://www.djcj.org/LAU/jack/
>
> I think that's everything.
>
> I got xruns by opening programs but my audio tools are rezound and
> ardour and they won't record much longer that 20 seconds before jack xruns.
>
> I was the original poster. I found that if I used the 2.4.2 kernel with
> the low-latency patch from
> http://www.zip.com.au/~akpm/linux/schedlat.html#downloads and then
> installed jack as above, I would get NO xruns using kde, ardour (has
> multiple windows) and a network going. I've tried 2.6, 2.6.1 and patched
> to -mm4 and mm5 but I get xruns within even fluxbox by doing the most
> labour-unintensive computer tasks.
>
> The -p option extends the buffer (is that the word?). Well, I didn't
> need it with the 2.4.2 but in the 2.6 I made it -p 8192. It only
> extended the xrun relief by a couple of seconds though. (ie it did jack
> all)

8192 samples at 48khz is an horrendously long time, over 150 ms... there must 
be something we've missed, clearly this should be possible to handle?

jack uses a rather clever ipc mechanism to contact all the clients with the 
least amount of context switches, I remember there was some talk about 2.4 
having trouble with it at times... (preventing us from going to 64 
samples..kind of trouble)...
Could it be that some similar issue affects 2.6, but much worse ? But then 
again, there are people running 2.6 with acceptable performance ???
Just throwing out ideas...

/Robert

>
> If you could throw any light on this then that would be absolutely great.





More information about the Linux-audio-user mailing list