11 Jan
2005
11 Jan
'05
9:35 a.m.
Hi all,
I'm wondering if anyone can explain the difference between an XRUN, and
an XRUN callback. Is an XRUN callback not a matter of great concern? (It
seems to me from reports in the qjackctl message window that no time is
actually lost). On my system at 11ms latency i get an XRUN callback
every 30 minutes or so and a true XRUN when something happens (open a
jack application, for instance).
Cheers,
Andres
11 Jan
11 Jan
10:15 a.m.
Andres Cabrera wrote:
Hi all,
I'm wondering if anyone can explain the difference between an XRUN, and
an XRUN callback. Is an XRUN callback not a matter of great concern? (It
seems to me from reports in the qjackctl message window that no time is
actually lost). On my system at 11ms latency i get an XRUN callback
every 30 minutes or so and a true XRUN when something happens (open a
jack application, for instance).
Qjackctl has two (2) codepaths to detect and report XRUNs.
One is optional and klunky, and probably still featured only for
historical reasons (!). That's this method of capturing all jackd's
stdout/stderr output and parsing it for the literal XRUN text message. As
it seems, this must be what you call a "true" XRUN, and appears on the
qjackctl messages windows colored in bright red (but with no timestamp).
The second one uses the JACK API, by registering a proper XRUN callback
procedure. That is the official way in which the jackd server notifies
registerd clients of a XRUN occurrence. This one appears on the qjackctl
messages window as a "XRUN callback" (pink?) message, prefixed by a
timestamp and includes a callback counter, which is also shown on the main
display--it's the number shown between the "(" and ")" if you
didn't
noticed.
Cheers.
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
1:15 p.m.
Hi Rui,
Thanks very much for your explanation. I remember there was a discussion
about this not too long ago, but I'm wondering if the xruns matter when
recording only. You could record at low latency, then raise it for
mixing and mastering (like you usually do on any system). Would this be
ok? Or would the recorded audio be missing small pieces?
Cheers,
Andres
Rui Nuno Capela wrote:
Andres Cabrera wrote:
Hi all,
I'm wondering if anyone can explain the difference between an XRUN, and
an XRUN callback. Is an XRUN callback not a matter of great concern? (It
seems to me from reports in the qjackctl message window that no time is
actually lost). On my system at 11ms latency i get an XRUN callback
every 30 minutes or so and a true XRUN when something happens (open a
jack application, for instance).
Qjackctl has two (2) codepaths to detect and report XRUNs.
One is optional and klunky, and probably still featured only for
historical reasons (!). That's this method of capturing all jackd's
stdout/stderr output and parsing it for the literal XRUN text message. As
it seems, this must be what you call a "true" XRUN, and appears on the
qjackctl messages windows colored in bright red (but with no timestamp).
The second one uses the JACK API, by registering a proper XRUN callback
procedure. That is the official way in which the jackd server notifies
registerd clients of a XRUN occurrence. This one appears on the qjackctl
messages window as a "XRUN callback" (pink?) message, prefixed by a
timestamp and includes a callback counter, which is also shown on the main
display--it's the number shown between the "(" and ")" if you
didn't
noticed.
Cheers.
1:25 p.m.
On Tue, 11 Jan 2005 12:11:54 -0500, Andres Cabrera
<andres(a)geminiflux.com> wrote:
Hi Rui,
Thanks very much for your explanation. I remember there was a discussion
about this not too long ago, but I'm wondering if the xruns matter when
recording only. You could record at low latency, then raise it for
mixing and mastering (like you usually do on any system). Would this be
ok? Or would the recorded audio be missing small pieces?
Cheers,
Andres
You cannot know for certain. If the xrun is Ardour not delivering
audio to the sound card then you get a click in the output audio. Not
a killer problem. If the xrun is Ardour not acquiring audio from the
sound card then the data is lost forever. Much bigger problem.
I would recommend that you record with latencies just high enough to
not be overly painful, and then push them higher when doing mixing if
you are not interfacing with external signal paths for post
processing.
- Mark
1:37 p.m.
Thanks Mark,
I guess it takes a little experimentation to find suitable settings. I'm
wondering though, that if the xrun reported says:
delay of 5132.000 usecs exceeds estimated spare time of 5009.000;
restart ...
All I'm losing is 0.1 ms of audio? These short xruns I see reported
aren't even audible on my good speakers, so I wouldn't mind (yes, I know
it's not ideal) losing this audio to have a lower latency.
Cheers,
Andrés
Mark Knecht wrote:
On Tue, 11 Jan 2005 12:11:54 -0500, Andres Cabrera
<andres(a)geminiflux.com> wrote:
Hi Rui,
Thanks very much for your explanation. I remember there was a discussion
about this not too long ago, but I'm wondering if the xruns matter when
recording only. You could record at low latency, then raise it for
mixing and mastering (like you usually do on any system). Would this be
ok? Or would the recorded audio be missing small pieces?
Cheers,
Andres
You cannot know for certain. If the xrun is Ardour not delivering
audio to the sound card then you get a click in the output audio. Not
a killer problem. If the xrun is Ardour not acquiring audio from the
sound card then the data is lost forever. Much bigger problem.
I would recommend that you record with latencies just high enough to
not be overly painful, and then push them higher when doing mixing if
you are not interfacing with external signal paths for post
processing.
- Mark
1:42 p.m.
I don't know when you lose audio and when you don't. I actually asked
an almost identical question on the Jack Developer's list about 60
days ago and got a long thread of answers and info in return. If you
have some time then scan their archives and find it. I think it's and
interesting read.
Other than that all I can say is that xruns are never good and you
need to adjust until you never get them at critical times.
Good luck,
Mark
On Tue, 11 Jan 2005 12:34:02 -0500, Andres Cabrera
<andres(a)geminiflux.com> wrote:
Thanks Mark,
I guess it takes a little experimentation to find suitable settings. I'm
wondering though, that if the xrun reported says:
delay of 5132.000 usecs exceeds estimated spare time of 5009.000;
restart ...
All I'm losing is 0.1 ms of audio? These short xruns I see reported
aren't even audible on my good speakers, so I wouldn't mind (yes, I know
it's not ideal) losing this audio to have a lower latency.
Cheers,
Andrés
Mark Knecht wrote:
On Tue, 11 Jan 2005 12:11:54 -0500, Andres
Cabrera
<andres(a)geminiflux.com> wrote:
Hi Rui,
Thanks very much for your explanation. I remember there was a discussion
about this not too long ago, but I'm wondering if the xruns matter when
recording only. You could record at low latency, then raise it for
mixing and mastering (like you usually do on any system). Would this be
ok? Or would the recorded audio be missing small pieces?
Cheers,
Andres
You cannot know for certain. If the xrun is Ardour not delivering
audio to the sound card then you get a click in the output audio. Not
a killer problem. If the xrun is Ardour not acquiring audio from the
sound card then the data is lost forever. Much bigger problem.
I would recommend that you record with latencies just high enough to
not be overly painful, and then push them higher when doing mixing if
you are not interfacing with external signal paths for post
processing.
- Mark
12 Jan
12 Jan
7:35 p.m.
New subject: [linux-audio-user] xruns with QJackCtl getting overloaded?
Hi,
speaking of xruns...
I tend to get a lot if I use my laptop on batteries and have the acpid
daemon running (sometimes also putting the performance profile down).
Now, even when I do not really hear anything from this xruns, the
problem usually is that QJackCtl starts to take up so much CPU, that
it becomes hard to solve the problem (bad mouse response, etc.).
Jack and other audio applications itself looks fine, just QJackCtl
gets up to above 90%.
I guess it has something to do with QJackCtl trying to inform me in
all detail about all these xruns, whereas I would be happy with just
the message "a lot of 'em" and much lower CPU-usage from QJackCtl.
I don't know whether this behaviour has been reported before (did not
check any other emaillists), but it is surely worth solving.
sincerely,
Marije
13 Jan
13 Jan
6:11 a.m.
New subject: [linux-audio-user] xruns with QJackCtl getting overloaded?
Marije,
There seem to be two problems here, and I have encountered both of them
recently.
1. QJackCtl going into overload: for me this happens if I run a process
that is CPU and hard disk intensive. For example if I do a 'find /
-iname filename' with QJackCtl, Jackd and a jack app running, QJackCtl
will increase its CPU usage until it crashes. Jackd itself, however does
not crash, and keeps running until you send it a HUP.
2. Xruns created by battery polls: I don't know if this is the same
problem that you are experiencing, but I used to run the gnome battstat
applet on my gnome panel. It took me a while to diagnose that this was
causing a lot of xruns, presumably every time it checks the battery
status. You might want to check that you don't have any status applets
running. You might also want to check that you don't have the kacpid
bug (check google for this).
Jamie
On Wed, 2005-01-12 at 19:53, nescivi wrote:
Hi,
speaking of xruns...
I tend to get a lot if I use my laptop on batteries and have the acpid
daemon running (sometimes also putting the performance profile down).
Now, even when I do not really hear anything from this xruns, the
problem usually is that QJackCtl starts to take up so much CPU, that
it becomes hard to solve the problem (bad mouse response, etc.).
Jack and other audio applications itself looks fine, just QJackCtl
gets up to above 90%.
I guess it has something to do with QJackCtl trying to inform me in
all detail about all these xruns, whereas I would be happy with just
the message "a lot of 'em" and much lower CPU-usage from QJackCtl.
I don't know whether this behaviour has been reported before (did not
check any other emaillists), but it is surely worth solving.
sincerely,
Marije
3:15 p.m.
New subject: [linux-audio-user] xruns with QJackCtl getting overloaded?
On Thu, 2005-01-13 at 10:10 +0000, Jamie Bullock wrote:
2. Xruns created by battery polls: I don't know if
this is the same
problem that you are experiencing, but I used to run the gnome battstat
applet on my gnome panel. It took me a while to diagnose that this was
causing a lot of xruns, presumably every time it checks the battery
status. You might want to check that you don't have any status applets
running. You might also want to check that you don't have the kacpid
bug (check google for this).
Known issue. Alan Cox sez "you have a severely broken BIOS that
implements ACPI via SMM". You would have exactly the same problem no
matter what OS you ran on it, because SMM bypasses the OS completely.
The only workaround is to disable ACPI daemons, batter monitors, etc
while doing audio work.
Lee
14 Jan
14 Jan
5:37 a.m.
New subject: Re[2]: [linux-audio-user] xruns with QJackCtl getting overloaded?
Hi,
Thursday, January 13, 2005, 11:10:58 AM, you wrote:
JB> 2. Xruns created by battery polls: I don't know if this is the same
JB> problem that you are experiencing, but I used to run the gnome battstat
JB> applet on my gnome panel. It took me a while to diagnose that this was
JB> causing a lot of xruns, presumably every time it checks the battery
JB> status. You might want to check that you don't have any status applets
JB> running. You might also want to check that you don't have the kacpid
JB> bug (check google for this).
This is probably the reason that I get xruns, and I suppose I should
find a solution for that (does anyone else have the problem on a
ThinkPad R51, 2.4.26 (debian) kernel?)
But the main thing that is annoying, that even when I have no audible
problem with this, QJackCtl (the GUI) is totally overloading the
system, as it wants to tell me constantly about this xruns.
I would like to know whether it would be possible to make it so that
the GUI would not get a signal for each xrun, but instead, if they
happen too often, only a signal once in a while. I think it should be
possible to create something in the interface, so that it only updates
once every 25 ms or 50 ms. That way it will not overload the system.
That way, I would still get the info from QJackCtl that there are a
lot of xruns, but I will still be able to do something about it,
without getting frustrated trying to move the mouse pointer around to
do so. I mean, I will not be able to read the info about each xrun at
the precise ms. so it can come a bit later and grouped. GUI updates
when they happen too often take a lot of processing time, so it would
be better to limit them in this case.
Sincerely,
Marije
6:28 a.m.
New subject: Re[2]: [linux-audio-user] xruns with QJackCtl getting overloaded?
nescivi wrote:
JB> 2. Xruns created by battery polls: I don't
know if this is the same
JB> problem that you are experiencing, but I used to run the gnome battstat
JB> applet on my gnome panel. It took me a while to diagnose that this was
JB> causing a lot of xruns, presumably every time it checks the battery
JB> status. You might want to check that you don't have any status applets
JB> running. You might also want to check that you don't have the kacpid
JB> bug (check google for this).
This is probably the reason that I get xruns, and I suppose I should
find a solution for that (does anyone else have the problem on a
ThinkPad R51, 2.4.26 (debian) kernel?)
I have the same nasty problem with the battery applet on an Acer TravelMate
notebook with a release candidate of DeMuDi 1.2.1.
But the main thing that is annoying, that even when I
have no audible
problem with this, QJackCtl (the GUI) is totally overloading the
system, as it wants to tell me constantly about this xruns.
The same here. And if it is "overloaded" it stays so for a long time because
then it is overloaded with the outputs of xruns which seems to lead to further
xruns etc. In effect I have to hit the stop button to get out of this cycle.
Cheers,
Andreas
6:38 a.m.
New subject: Re[2]: [linux-audio-user] xruns with QJackCtl getting overloaded?
On Friday 14 Jan 2005 10:30, Andreas Kuckartz wrote:
I have the same nasty problem with the battery applet
on an Acer
TravelMate notebook with a release candidate of DeMuDi 1.2.1.
In my experience, Acer laptops generally suffer from the poor ACPI
implementation Lee Revell referred to. You're best off switching off
ACPI altogether, if you can live without the battery level warning.
As Lee said, this problem is not unique to Linux.
Chris
7:03 a.m.
New subject: Re[2]: [linux-audio-user] xruns with QJackCtl getting overloaded?
Chris Cannam wrote:
In my experience, Acer laptops generally suffer from
the poor ACPI
implementation Lee Revell referred to. You're best off switching off
ACPI altogether, if you can live without the battery level warning.
As Lee said, this problem is not unique to Linux.
I have found a link to this kernel patch
http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/
on this page
http://nemadema.cz/acer/
Did anyone here try a kernel with that patch?
Cheers,
Andreas
7:48 a.m.
New subject: Re[2]: [linux-audio-user] xruns with QJackCtl getting overloaded?
nescivi wrote:
Thursday, January 13, 2005, 11:10:58 AM, you wrote:
JB> 2. Xruns created by battery polls: I don't know if this is the same
JB> problem that you are experiencing, but I used to run the gnome
battstat
JB> applet on my gnome panel. It took me a while to diagnose that this was
JB> causing a lot of xruns, presumably every time it checks the battery
JB> status. You might want to check that you don't have any status applets
JB> running. You might also want to check that you don't have the kacpid
JB> bug (check google for this).
This is probably the reason that I get xruns, and I suppose I should
find a solution for that (does anyone else have the problem on a
ThinkPad R51, 2.4.26 (debian) kernel?)
But the main thing that is annoying, that even when I have no audible
problem with this, QJackCtl (the GUI) is totally overloading the
system, as it wants to tell me constantly about this xruns.
I would like to know whether it would be possible to make it so that
the GUI would not get a signal for each xrun, but instead, if they
happen too often, only a signal once in a while. I think it should be
possible to create something in the interface, so that it only updates
once every 25 ms or 50 ms. That way it will not overload the system.
That way, I would still get the info from QJackCtl that there are a
lot of xruns, but I will still be able to do something about it,
without getting frustrated trying to move the mouse pointer around to
do so. I mean, I will not be able to read the info about each xrun at
the precise ms. so it can come a bit later and grouped. GUI updates
when they happen too often take a lot of processing time, so it would
be better to limit them in this case.
I'll see what I can do about, like tracking the XRUN frequency/rate and
bypass the display (e.g. messages window) if it gets too high. That
assumes thats the cost of rendering the XRUN messages lines that is hosing
qjackctl.
Bye now.
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
7304
days inactive
7307
days old
linux-audio-user@lists.linuxaudio.org
13 comments
8 participants
participants (8)
-
Andreas Kuckartz -
Andres Cabrera -
Chris Cannam -
Jamie Bullock -
Lee Revell -
Mark Knecht -
nescivi -
Rui Nuno Capela