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 <[EMAIL PROTECTED]> 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
[email protected]
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
