On Wed, 29 Mar 2006 09:57:50 +0200
Dominic Sacré <dominic.sacre@email-addr-hidden> 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.orgReceived on Wed Mar 29 12:15:08 2006
This archive was generated by hypermail 2.1.8 : Wed Mar 29 2006 - 12:15:09 EEST