Subject: Re: [linux-audio-user] Which kernel for low latency and kernel 2.6.1-mm# problems
From: Glenn McCord (clari_player_AT_paradise.net.nz)
Date: Thu Jan 22 2004 - 17:33:50 EET
Robert Jonsson wrote:
>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.
>
With a jackstart -R -v -d alsa -d hw:0 -p 1024 I can get away with it If
I just look at it (I'm in fluxbox). But If open/close mozilla (ie. do
stuff) I get xruns.
>
>
>
>>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.
>>
>>
>
>
>
>
>
>
This archive was generated by hypermail 2b28 : Thu Jan 22 2004 - 04:32:06 EET