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

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-user] Which kernel for low latency and kernel 2.6.1-mm# problems
From: Robert Jonsson (robert.jonsson_AT_dataductus.se)
Date: Thu Jan 22 2004 - 00:48:12 EET


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.


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Thu Jan 22 2004 - 00:44:42 EET