On Wed, 29 Mar 2006 09:57:50 +0200 Dominic Sacré <dominic.sacre@xxxxxx> wrote: > Hi, > > I'm trying to set up my Ubuntu Dapper system to work reliably with > reasonably low latency, but I'm unable to really eliminate xruns. It works > quite well most of the time, but sooner or later I'll inevitably get > xruns, usually when starting/closing jack-apps, or sometimes when > starting/stopping playback. Some jack apps are badly programmed and start up/shut down in a non realtime safe way. I.e. jack-rack _always_ produces an xrun on shutdown. Starting/Stopping playback with what? > My machine is an Athlon XP 3000+, with VIA chipset and 2 SATA disks. > The sound card is an M-Audio Audiophile 2496, and my aim would be to run > jack at 5.8ms latency (-r44100 -p128 -n2) or less. Which should be possible with a -rt kernel. > I already tried pretty much everything I could thinks of, that is: > > - Installed a realtime kernel (currently 2.6.16.1-rt11) good, although it might be wise to try different versions. > - Used the nv display driver instead of nvidia good > - Switched PCI slots around so that the Audiophile doesn't share an IRQ > with the graphics card (an IRQ solely for the Audiophile doesn't seem > possible, it now shares an IRQ with a SBlive) which is ok > - Changed filesystems from reiserfs to ext3 (/) and xfs (/home) might be good. no idea. i never ad trouble with ext3. But besides ext2 i never tried any other fs's ;) I heard bad things about xfs though. Do you record to /home? > I'm running jack at rtprio 70, and also set the sound card IRQ's priority > to 99, but none of that seems to make a difference. good > I have latency tracing enabled, but I can't make head or tail of it, to me > it looks like the xruns occur at random... > > Now I'm at a loss. What else can I do? If you are really willing to hunt these xruns down you can compile jackd with --enable-preemption-check. You also need to have user triggered tracing enabled in the -rt kernel for this. Now everytime an app does rt unsafe stuff in its callback that causes the app to lose the cpu to another app, the kernel will send it a SIGUSR2 and the app will probably terminate due to it ot handling this signal. You will also get a stack trace in the syslog which tells you what happened in the app and which app it was. Flo -- Palimm Palimm! http://tapas.affenbande.org
