11 Jul
2007
11 Jul
'07
5:26 p.m.
We're doing an ARM-based embedded device, which right now is running
vanilla 2.6.20. For the sake of simplicity we wrote an OSS driver
that's simply double-buffering and writing to the DAC via I2S. We
have a buffer underrun problem that is directly proportional to CPU
load... no glitches when simply cat-ing a file to /dev/dsp, but lots
of glitches when other things are happening on the system. Can
anyone suggest tools/techniques/patches for improving the situation?
Use an alternative scheduler? Figure out which driver might be
turning interrupts off for too long? We're using 20ms buffers which
seems pretty generous.
I know this is a bit of a noob question, but any advice or pointers
to info much appreciated.
darren
11 Jul
11 Jul
5:34 p.m.
On 7/11/07, Darren Gibbs <tsquank(a)yahoo.com> wrote:
We're doing an ARM-based embedded device, which
right now is running
vanilla 2.6.20. For the sake of simplicity we wrote an OSS driver
that's simply double-buffering and writing to the DAC via I2S. We
have a buffer underrun problem that is directly proportional to CPU
load... no glitches when simply cat-ing a file to /dev/dsp, but lots
of glitches when other things are happening on the system. Can
anyone suggest tools/techniques/patches for improving the situation?
Run the audio playback app with SCHED_FIFO priority.
Lee
6:58 p.m.
Thanks, cool... that solves the glitching that scales with CPU load,
I still have more rare glitches (every few seconds) that look like
buffer underruns. I'm suspect this is because some other kernel
entity has interrupts turned off when the DMA interrupt needs to be
serviced to switch buffers. Are there any clever tools for figuring
out who might be doing this?
On Jul 11, 2007, at 12:33 PM, Lee Revell wrote:
On 7/11/07, Darren Gibbs <tsquank(a)yahoo.com>
wrote:
We're doing an ARM-based embedded device,
which right now is running
vanilla 2.6.20. For the sake of simplicity we wrote an OSS driver
that's simply double-buffering and writing to the DAC via I2S. We
have a buffer underrun problem that is directly proportional to CPU
load... no glitches when simply cat-ing a file to /dev/dsp, but lots
of glitches when other things are happening on the system. Can
anyone suggest tools/techniques/patches for improving the situation?
Run the audio playback app with SCHED_FIFO priority.
Lee
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
12 Jul
12 Jul
1:27 p.m.
So the story is more interesting now... with SCHED_FIFO I'm seeing
occational delays of about 60 sample frames (@44K) when there is very
little other CPU activity. It still looks like a buffer underrun in
that the audio data is contiguous on both sides of the delay, so I'm
not dropping a buffer. When I load the CPU with another task doing a
while(1) loop, the glitches go away. Hmmm....
On Jul 11, 2007, at 1:57 PM, Darren Gibbs wrote:
Thanks, cool... that solves the glitching that scales
with CPU
load, I still have more rare glitches (every few seconds) that look
like buffer underruns. I'm suspect this is because some other
kernel entity has interrupts turned off when the DMA interrupt
needs to be serviced to switch buffers. Are there any clever tools
for figuring out who might be doing this?
On Jul 11, 2007, at 12:33 PM, Lee Revell wrote:
> On 7/11/07, Darren Gibbs <tsquank(a)yahoo.com> wrote:
>> We're doing an ARM-based embedded device, which right now is running
>> vanilla 2.6.20. For the sake of simplicity we wrote an OSS driver
>> that's simply double-buffering and writing to the DAC via I2S. We
>> have a buffer underrun problem that is directly proportional to CPU
>> load... no glitches when simply cat-ing a file to /dev/dsp, but lots
>> of glitches when other things are happening on the system. Can
>> anyone suggest tools/techniques/patches for improving the situation?
>
> Run the audio playback app with SCHED_FIFO priority.
>
> Lee
3:23 p.m.
On 7/12/07, Darren Gibbs <tsquank(a)yahoo.com> wrote:
So the story is more interesting now... with
SCHED_FIFO I'm seeing
occational delays of about 60 sample frames (@44K) when there is very
little other CPU activity. It still looks like a buffer underrun in
that the audio data is contiguous on both sides of the delay, so I'm
not dropping a buffer. When I load the CPU with another task doing a
while(1) loop, the glitches go away. Hmmm....
You will probably need to run an -rt patched kernel to get acceptable
performance from JACK. This also includes a cool latency tracing
feature that will tell you what IRQ handler is using too much CPU
time.
Lee
15 Jul
15 Jul
8:13 a.m.
On Thursday 12 July 2007 20:23:02 Lee Revell wrote:
On 7/12/07, Darren Gibbs <tsquank(a)yahoo.com>
wrote:
Joining in on this discussion. What feature is this, and how does one use it?
I need to diagnose my system for the source of constant XRUNs.
Juuso
So the story is more interesting now... with
SCHED_FIFO I'm seeing
occational delays of about 60 sample frames (@44K) when there is very
little other CPU activity. It still looks like a buffer underrun in
that the audio data is contiguous on both sides of the delay, so I'm
not dropping a buffer. When I load the CPU with another task doing a
while(1) loop, the glitches go away. Hmmm....
You will probably need to run an -rt patched kernel to get acceptable
performance from JACK. This also includes a cool latency tracing
feature that will tell you what IRQ handler is using too much CPU
time. 
12:09 p.m.
On Thursday 12 July 2007 20:23:02 Lee Revell wrote:
> ...a cool latency tracing feature...
Juuso Alasuutari wrote:
...What feature is this, and how does one use it?
I was also curious about this. Are you referring to
/proc/latency_trace? If so, I haven't been able to get any meaningful
output from it recently; I think it now just lists thread_exit() and not
a full stack trace like I think it's supposed to. I therefore can't
tell where any latency actually comes from, and all I know is which
process induced it. Are there any specific kernel options that must or
must not be enabled to get the full stack trace?
Thanks!
--
Steven Chamberlain
steven(a)pyro.eu.org
6137
days inactive
6141
days old
linux-audio-dev@lists.linuxaudio.org
7 comments
5 participants
participants (5)
-
Darren Gibbs -
Jussi Laako -
Juuso Alasuutari -
Lee Revell -
Steven Chamberlain