Re: [linux-audio-dev] xruns

From: Paul Davis <paul@email-addr-hidden>
Date: Wed Nov 23 2005 - 15:54:21 EET

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
Received on Wed Nov 23 16:15:06 2005

This archive was generated by hypermail 2.1.8 : Wed Nov 23 2005 - 16:15:07 EET