2 Nov
2005
2 Nov
'05
10:34 a.m.
Hello list,
well i try to understand the reason of xruns. when will they appear?
for me it's curious, that , while copy a big file (> 50MB ) or many small one,
there are xruns. so, it seems, that it has nothing to do with the soundcard
buffers.
any comments?
sizu c~
2 Nov
2 Nov
1:35 p.m.
On Wed, 2 Nov 2005 15:30:49 +0100
conrad berhörster <conrad.berhoerster(a)gmx.de> wrote:
Hello list,
well i try to understand the reason of xruns. when will they appear?
for me it's curious, that , while copy a big file (> 50MB ) or many small one,
there are xruns. so, it seems, that it has nothing to do with the soundcard
buffers.
any comments?
Well, yeah. First of all your question is very unprecise. I will try to
guess the blanks.
1) you are probably talking about jackd as most other alsa apps don't
even report their xruns
2) you are probably not running a realtime preemption or other low
latency kernel
3) you are not running jack with the realtime flag (-R)
The reason for an xrun is basically:
The process consuming/producing audio did not do this fast enough (Audio
is processed in chunks and you have the time equivalent to one chunk of
audio to produce/consume it).
This can have many reasons:
- you ask too much of your computer (like the computations involved are
simply too complex). This would produce a constant stream of xruns
though. I suppose you probably see much less then 1 per
periodsize/samplerate sec.
- this is the more probable reason: Some other process on your system
kept your audio producing/consuming process from doing its thang.
This second one can be remedied by changing step 2 and 3 above.
There's two more potential reasons which i can think of right now:
4) your jack tmpfs is not mounted on a tmpfs or shmfs filesystem
5) NPTL hell (google for this one)
Have fun,
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
17 Nov
17 Nov
2:06 p.m.
Thanks florian, this gave a lot of insight.
Am Mittwoch 02 November 2005 18:35 schrieb Florian Schmidt:
Well, yeah. First of all your question is very unprecise. I will try to
guess the blanks.
Sorry for that. your guessing was quiet right.
1) you are probably talking about jackd as most other alsa apps don't
even report their xruns
ever thought xrun is a jack thing
2) you are probably not running a realtime preemption or other low
latency kernel
3) you are not running jack with the realtime flag (-R)
ok i have done that.
The reason for an xrun is basically:
The process consuming/producing audio did not do this fast enough (Audio
is processed in chunks and you have the time equivalent to one chunk of
audio to produce/consume it).
This can have many reasons:
- you ask too much of your computer (like the computations involved are
simply too complex). This would produce a constant stream of xruns
though. I suppose you probably see much less then 1 per
periodsize/samplerate sec.
- this is the more probable reason: Some other process on your system
kept your audio producing/consuming process from doing its thang.
fixed
This second one can be remedied by changing step 2 and
3 above.
There's two more potential reasons which i can think of right now:
4) your jack tmpfs is not mounted on a tmpfs or shmfs filesystem
fixed
5) NPTL hell (google for this one)
Have fun,
Flo
my app runs quite right, in the normal play mode. then i started adding some
effects. after adding 6 x 31 band eqs i have tons of xruns. but the cpu is
only at 60% . A friend of mine told me, this can be because of the usage of
only one jack buffer.
this means
- get jack callback
- get the buffer from jack
- fill the buffer with data
- copy it back to jack
is there a way to specify more than one buffer with jack ( like direct sound )
or do i need the ringbuffer. maybe someone can give my a link to an example.
thanks c~
20 Nov
20 Nov
8:27 a.m.
my app runs quite right, in the normal play mode. then
i started adding some
effects. after adding 6 x 31 band eqs i have tons of xruns. but the cpu is
only at 60% . A friend of mine told me, this can be because of the usage of
only one jack buffer.
this means
- get jack callback
- get the buffer from jack
- fill the buffer with data
- copy it back to jack
is there a way to specify more than one buffer with jack ( like direct sound )
or do i need the ringbuffer. maybe someone can give my a link to an example.
you friend is wrong. JACK's default configuration (2 software buffers or
interrupts per hardware buffer) is the same as ASIO. You can use the -n
flag or the equivalent control in the setup dialog of qjackctl to get
more, but there are many cards that will only accept specific
combinations of software buffer counts and sample rate. you may have to
experiment to find the best.
however, this is not necessarily the right approach to handling xruns.
its worth trying. a better start is to check if the xruns go away or
occur less frequently with a larger buffer size.
--p
8:46 a.m.
its worth trying. a better start is to check if the
xruns go away or
occur less frequently with a larger buffer size.
I even got good results by disabling some hardware (there have been some
shared IRQs on my system).
cat /proc/interrupts
will show you more details. I disabled the nvidia driver and enabled the
x-org nv driver. This did help a lot because the nvidia driver shared
interrupt 11 with the USB controller (I'm running JACK on top of a USB
soundcard).
Best regards
ce
»Wer Visionen hat, sollte zum Arzt gehen« (Helmut Schmidt)
10:07 a.m.
On Sun, Nov 20, 2005 at 08:29:37AM -0500, Paul Davis wrote:
however, this is not necessarily the right approach to
handling xruns.
its worth trying. a better start is to check if the xruns go away or
occur less frequently with a larger buffer size.
USB cards often work a lot better (allow much smaller buffer sizes)
when used with 3 periods instead of 2 when Fs = 48 kHz. Apparently
having a total buffer size that is a multiple of 48 helps.
--
FA
10:33 a.m.
USB cards
often work a lot better (allow much smaller buffer sizes)
when used with 3 periods instead of 2 when Fs = 48 kHz. Apparently
having a total buffer size that is a multiple of 48 helps.
I can confirm that by trial and error experiments.
23 Nov
23 Nov
8:14 a.m.
Am Sonntag 20 November 2005 14:29 schrieb Paul Davis:
hi Paul,
thanks to your reply. I think, i should describe my problem more detailed.
For a customer, wrote an app for a 5.1 system. The system is slackware box and
this terratec phase 28 card. the kernel is a rt patched 2.6.14
All of the 6 channels need to have a 10 -band EQ, an 31-band EQ, and a
reverb. Each effect works well if i only use it alone. But if i try to set
them up in a chain, i got tons of xruns. the app is (roughly described)
implemented as the example clients . as described above, the app only
produces the sound only, if it's needed.
my inner voices (oh well, lots of them) tell me, that the app doesn't provide
enough sounddata to jack. so jack aka ALSA produces an xrun. right ?
what puzzles me, is the fact, that the CPU is only at 60% . so there is enough
power, to produce the data .
The first idea was, to handle one buffer for each channel. this i would do
with APIs like DirectSound.
But since JACK only handles 2 buffers as default, the app can provide this
buffers and copy the data into the JACK buffer. are there any comments for
this disposition.
How big should this buffers are.
and a word to christoph: i had could be a possibility, but IRQ 10 is only used
once - from the soundcard.
thanks for comments c~
my app runs
quite right, in the normal play mode. then i started adding
some effects. after adding 6 x 31 band eqs i have tons of xruns. but
the cpu is only at 60% . A friend of mine told me, this can be because of
the usage of only one jack buffer.
this means
- get jack callback
- get the buffer from jack
- fill the buffer with data
- copy it back to jack
is there a way to specify more than one buffer with jack ( like direct
sound ) or do i need the ringbuffer. maybe someone can give my a link to
an example.
you friend is wrong. JACK's default configuration (2 software buffers or
interrupts per hardware buffer) is the same as ASIO. You can use the -n
flag or the equivalent control in the setup dialog of qjackctl to get
more, but there are many cards that will only accept specific
combinations of software buffer counts and sample rate. you may have to
experiment to find the best.
however, this is not necessarily the right approach to handling xruns.
its worth trying. a better start is to check if the xruns go away or
occur less frequently with a larger buffer size.
--p
8:24 a.m.
Am Sonntag 20 November 2005 14:29 schrieb Paul Davis:
hi Paul,
thanks to your reply. I think, i should describe my problem more detailed.
For a customer, wrote an app for a 5.1 system. The system is slackware box and
this terratec phase 28 card. the kernel is a rt patched 2.6.14
All of the 6 channels need to have a 10 -band EQ, an 31-band EQ, and a
reverb. Each effect works well if i only use it alone. But if i try to set
them up in a chain, i got tons of xruns. the app is (roughly described)
implemented as the example clients . as described above, the app only
produces the sound only, if it's needed.
my inner voices (oh well, lots of them) tell me, that the app doesn't provide
enough sounddata to jack. so jack aka ALSA produces an xrun. right ?
what puzzles me, is the fact, that the CPU is only at 60% . so there is enough
power, to produce the data .
The first idea was, to handle one buffer for each channel. this i would do
with APIs like DirectSound.
But since JACK only handles 2 buffers as default, the app can provide this
buffers and copy the data into the JACK buffer. are there any comments for
this disposition.
How big should this buffers are.
and a word to christoph: i had could be a possibility, but IRQ 10 is only used
once - from the soundcard.
thanks for comments c~
my app runs
quite right, in the normal play mode. then i started adding
some effects. after adding 6 x 31 band eqs i have tons of xruns. but
the cpu is only at 60% . A friend of mine told me, this can be because of
the usage of only one jack buffer.
this means
- get jack callback
- get the buffer from jack
- fill the buffer with data
- copy it back to jack
is there a way to specify more than one buffer with jack ( like direct
sound ) or do i need the ringbuffer. maybe someone can give my a link to
an example.
you friend is wrong. JACK's default configuration (2 software buffers or
interrupts per hardware buffer) is the same as ASIO. You can use the -n
flag or the equivalent control in the setup dialog of qjackctl to get
more, but there are many cards that will only accept specific
combinations of software buffer counts and sample rate. you may have to
experiment to find the best.
however, this is not necessarily the right approach to handling xruns.
its worth trying. a better start is to check if the xruns go away or
occur less frequently with a larger buffer size.
--p
8:52 a.m.
On Wed, 2005-11-23 at 13:25 +0100, conrad berhörster wrote:
thanks to your reply. I think, i should describe my
problem more detailed.
For a customer, wrote an app for a 5.1 system. The system is slackware box and
this terratec phase 28 card. the kernel is a rt patched 2.6.14
All of the 6 channels need to have a 10 -band EQ, an 31-band EQ, and a
reverb. Each effect works well if i only use it alone. But if i try to set
them up in a chain, i got tons of xruns. the app is (roughly described)
implemented as the example clients . as described above, the app only
produces the sound only, if it's needed.
my inner voices (oh well, lots of them) tell me, that the app doesn't provide
enough sounddata to jack. so jack aka ALSA produces an xrun. right ?
what puzzles me, is the fact, that the CPU is only at 60% . so there is enough
power, to produce the data .
The first idea was, to handle one buffer for each channel. this i would do
with APIs like DirectSound.
But since JACK only handles 2 buffers as default, the app can provide this
buffers and copy the data into the JACK buffer. are there any comments for
this disposition.
How big should this buffers are.
i don't think it will be easy to help you until we get some terminology
fixed. in the ALSA/JACK world:
* "buffer size" is the total size of the buffer used by the
hardware (measured in frames) [unnamed in DirectSound/ASIO]
* "period size" is the number of frames processed by the h/w
between interrupts ["buffer size" in DirectSound/ASIO]
the buffer size is the period size multiplied by the number of periods.
to increase latency and reduce the chance of xruns, you can increase the
period size and/or the number of periods.
what period size are you using with JACK, and how many periods are you
using (this can all be seen within the setup dialog of qjackctl, or
from the command line) ?
i have no real idea what you mean by "1 buffer per channel". in JACK,
every "channel" is represented by a "port", and in every process
cycle,
your app is expected to read the data from its input ports and fill its
output ports. each port has a "buffer" that you can read/write from/to.
where do the effects you are using come from? also, 60% CPU is actually
not far from the threshold where xruns start to become predictable. the
best measure of how hard your system is working comes from the JACK "DSP
load" displayed in qjackctl's status window. From our tests on OS X and
Linux, once you get to about 80% DSP load, xruns are just around the
corner, because of the variance in response time within a general
purpose OS (even one with the kinds of RT performance that modern linux
and OS X have). so what kind of DSP load do you see?
--p
24 Nov
24 Nov
9:30 a.m.
Hallo Paul,
Am Mittwoch 23 November 2005 14:54 schrieb Paul Davis:
where do the effects you are using come from? also, 60% CPU is actually
not far from the threshold where xruns start to become predictable. the
best measure of how hard your system is working comes from the JACK "DSP
load" displayed in qjackctl's status window. From our tests on OS X and
Linux, once you get to about 80% DSP load, xruns are just around the
corner, because of the variance in response time within a general
purpose OS (even one with the kinds of RT performance that modern linux
and OS X have). so what kind of DSP load do you see?
ok, here is my update. i installed qjackctl. i tried to use the system without
qjackctl, because i wanted to implement remote via ssh. is there a
possibility to get the CPU time and further info just with the standard tools
jack_lsp etc. haven't found that. so far i got my CPU info for the command
tool top. With jackctl the CPU with
jackd -R -dalsa -dhw:0 -r44100 -p1024 -n2
is around 95 % , thats bad, he!
i started playing around with the Framesize up to 4096 , but this doesn't have
any effect. than i started varify the SampleRate down to 22050. with that i
got a CPU around 55% command was
jackd -R -dalsa -dhw:0 -r22050 -p1024 -n2
Also, i got tons of xRUNs.
today, i try to install the new RT patches as Lee recommended.
and for terminology fixing. is there any difference between the CPU/Processor
and the DSP in an standard box (not special boards)
sizu c~
6967
days inactive
6989
days old
linux-audio-dev@lists.linuxaudio.org
12 comments
7 participants
participants (7)
-
Christoph Eckert -
conrad berhörster -
Florian Schmidt -
fons adriaensen -
Lee Revell -
Luis Garrido -
Paul Davis