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

[Glenn McCord]

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