[linux-audio-user] Can't get rid of xruns

[Florian Schmidt]

On Wed, 29 Mar 2006 16:35:11 +0200
Dominic Sacré <dominic.sacre at gmx.de> wrote:

> On Wednesday, 29. March 2006 10:50, Florian Schmidt wrote:
> > 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.
> 
> Well, this seems to be application dependent. I have not seen any xruns 
> caused by ardour, for instance. On the other hand, rezound causes xruns 
> all the time (usually a few at startup, and then occasionally some 
> when "doing something"). I've also seen xruns when starting/shutting down 
> jamin, rosegarden, muse, jack-rack, xfst... Are all these apps broken?!

Probably yes. Writing a non trivial app in a realtime safe way is
sadly not trivial at all :)

> > > - Installed a realtime kernel (currently 2.6.16.1-rt11)
> > good, although it might be wise to try different versions.
> 
> I did. I used various versions of 2.6.12, 2.6.15 and 2.6.16 with the 
> respective realtime patches, same result.

And i suppose you also had the priorities setup similar to your current
setup right?

> I'm recording to /home on xfs, but as most xruns occur during 
> startup/shutdown, this doesn't seem to be the issue, does it?

As ardour runs xrun free while recording to the very same disc is
suppose we can rule that out.

This also gives a pretty strong hint about the brokenness of the other
apps. If ardour, a very complex nontrivial app, gets it right and
produces no xruns, but other apps do, this is a strong indicator for the
brokenness of the other apps.

> > 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.
> 
> Ok, I did that. Doesn't seem to have an effect on most apps though. 
> Rosegarden, rezound and jack_rack all caused xruns, but none of them was 
> terminated, and there's no stack trace either.
> However I got a stack trace when shutting down jamin:

The preemption check actually checks only for one class of realtime
violations: Those where the app gives up the cpu volountarily (due to
using non rt safe calls that consequently make the process go to sleep).

There's yet another class of realtime unsafeness: Simply taking too long
in the process callback. If the period is i.e. 10 ms, and the app needs
20 ms you get an xrun although the app never gave up the cpu
volountarily.

> 
> [ 4797.602341] jamin:17931 userspace BUG: scheduling in user-atomic 
> context!
> [ 4797.602362]  [<c01049f5>] show_trace+0x25/0x30 (20)
> [ 4797.602382]  [<c0104a23>] dump_stack+0x23/0x30 (20)
> [ 4797.602395]  [<c02bfa64>] schedule+0x114/0x140 (36)
> [ 4797.602412]  [<c02bfda4>] wait_for_completion+0xa4/0xe0 (48)
> [ 4797.602426]  [<c017bb68>] do_coredump+0x348/0x780 (192)
> [ 4797.602456]  [<c012edf1>] get_signal_to_deliver+0x391/0x510 (60)
> [ 4797.602473]  [<c0102c68>] do_notify_resume+0xb8/0x75c (220)
> [ 4797.602486]  [<c01034fc>] work_notifysig+0x13/0x1b (-8116)
> [ 4797.602498] ---------------------------
> [ 4797.602504] | preempt count: 00000000 ]
> [ 4797.602511] | 0-level deep critical section nesting:
> [ 4797.602518] ----------------------------------------
> 
> What does that mean?

This gives you a clue about what system call/code path in the kernel
caused the volountary giving up of cpu.

To find out what the app did to produce this behaviour, build the app
with debug symbols, and eiter run it in gdb or do ulimit -c unlimited
and examine the core after the app got terminated (it will dump a core)
with gdb.

Flo

-- 
Palimm Palimm!
http://tapas.affenbande.org