29 Mar
2006
29 Mar
'06
5:02 a.m.
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.
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.
I already tried pretty much everything I could thinks of, that is:
- Installed a realtime kernel (currently 2.6.16.1-rt11)
- Used the nv display driver instead of nvidia
- 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)
- Changed filesystems from reiserfs to ext3 (/) and xfs (/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.
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?
Thanks,
Dominic
29 Mar
29 Mar
5:51 a.m.
On Wed, 29 Mar 2006 09:57:50 +0200
Dominic Sacré <dominic.sacre(a)gmx.de> 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
11:39 a.m.
On Wednesday, 29. March 2006 10:50, Florian Schmidt wrote:
I did. I used various versions of 2.6.12, 2.6.15 and 2.6.16 with the
respective realtime patches, same result.
The predominant opinion seems to be that both ext3 and xfs are ok, if I'm
not mistaken. But I haven't heard a definite answer to which filesystem
is best, yet.
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?
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?!
- Installed a
realtime kernel (currently 2.6.16.1-rt11)
good, although it might be wise to try
different versions. - 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? 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:
[ 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?
Thanks,
Dominic
12:28 p.m.
On Wed, 29 Mar 2006 16:35:11 +0200
Dominic Sacré <dominic.sacre(a)gmx.de> wrote:
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?
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.
On Wednesday, 29. March 2006 10:50, Florian Schmidt
wrote:
Probably yes. Writing a non trivial app in a realtime safe way is
sadly not trivial at all :)
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?! - Installed a realtime kernel (currently
2.6.16.1-rt11)
good, although it might be wise to try different versions. 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:
[ 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
4:31 p.m.
On Wed, 2006-03-29 at 17:28 +0200, Florian Schmidt wrote:
Doesn't this trace mean the problem is that jamin actually crashed and
dumped core on exit?
Lee
[ 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.
30 Mar
30 Mar
10:04 p.m.
On Wednesday, 29. March 2006 21:08, Lee Revell wrote:
On Wed, 2006-03-29 at 17:28 +0200, Florian Schmidt
wrote:
> > [ 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] ----------------------------------------
Doesn't this trace mean the problem is that jamin
actually crashed and
dumped core on exit?
You're right... This is the backtrace:
#0 0xffffe410 in __kernel_vsyscall ()
#1 0x451a69a1 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0x451a82b9 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0x0805a69e in io_queue (nframes=0, nchannels=2, in=0xb73e03c4,
out=0xb73e03bc) at io.c:477
#4 0x0805a7c5 in io_process (nframes=64, arg=0x0) at io.c:545
#5 0xb7f7d7c7 in jack_client_thread (arg=0x8120c00) at client.c:1465
#6 0xb7f80e04 in jack_thread_proxy (varg=0x82324a8) at thread.c:111
#7 0x453e0341 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#8 0x452474de in clone () from /lib/tls/i686/cmov/libc.so.6
So jamin is actually calling abort() at io.c:477. But why? What is
happening here, and what can I do about it?
Dominic
29 Mar
29 Mar
5:25 p.m.
On Wed, Mar 29, 2006 at 05:28:06PM +0200, Florian Schmidt wrote:
On Wed, 29 Mar 2006 16:35:11 +0200
Dominic Sacr? <dominic.sacre(a)gmx.de> wrote:
jackd produces xruns most of the time when the process graph is
reordered. which occurs on start stop of apps and port connection.
ignore these xruns. they are not a problem.
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
On Wednesday, 29. March 2006 10:50, Florian
Schmidt wrote:
Probably yes. Writing a non trivial app in a realtime safe way is
sadly not trivial at all :) 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?!
5:47 p.m.
On Wed, 2006-03-29 at 22:21 +0200, torbenh(a)gmx.de wrote:
jackd produces xruns most of the time when the process
graph is
reordered. which occurs on start stop of apps and port connection.
ignore these xruns. they are not a problem.
Some of them are - a bug was just found in Ardour where stopping the
transport can cause it to unlink() in the process callback causing an
xrun.
If it's a real xrun it will either show up in the regular latency tracer
(/proc/latency_trace) or the user triggered atomicity debugger
(described earlier in the thread).
Lee
30 Mar
30 Mar
10:14 p.m.
On Wednesday, 29. March 2006 22:21, torbenh(a)gmx.de wrote:
jackd produces xruns most of the time when the process
graph is
reordered. which occurs on start stop of apps and port connection.
ignore these xruns. they are not a problem.
Well, maybe they aren't. But with qjackctl's xrun counter being nonzero
most of the time I tend to not notice when an xrun occurs during
recording...
Dominic
11:29 p.m.
On Fri, 2006-03-31 at 03:13 +0200, Dominic Sacré wrote:
On Wednesday, 29. March 2006 22:21, torbenh(a)gmx.de
wrote:
Enable the tray icon, then before you do any recording stuff,
right-click and Reset the counter.
Dana
jackd produces xruns most of the time when the
process graph is
reordered. which occurs on start stop of apps and port connection.
ignore these xruns. they are not a problem.
Well, maybe they aren't. But with qjackctl's xrun counter being nonzero
most of the time I tend to not notice when an xrun occurs during
recording...
Dominic
10:04 p.m.
On Wednesday, 29. March 2006 17:28, Florian Schmidt wrote:
At least on 2.6.15 and 2.6.16, yes (with several different versions of the
realtime patch). I don't think I ever used chrt on a 2.6.12 kernel,
because I hadn't read your "Ramblings on linux audio/midi system setup"
back then :)
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? 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).
Ok, I see... So these xruns can only be remedied by fixing the apps, not
by changing my system configuration?
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.
How do I catch those errors? Using the latency tracer? Or does that only
report latencies within the kernel?
Anyway, I think I could do with some explanation how to use it, and how
to interpret the contents of /proc/latency_trace...
Dominic
6814
days inactive
6815
days old
linux-audio-user@lists.linuxaudio.org
10 comments
5 participants
participants (5)
-
Dana Olson -
Dominic Sacré -
Florian Schmidt -
Lee Revell -
torbenh＠gmx.de