On 10/26/2012 03:02 AM, Ken Restivo wrote:
On Fri, Oct 26, 2012 at 08:35:00AM +0200, Clemens Ladisch wrote:
Ken Restivo wrote:
I've heard audio stutter briefly on machines, usually under heavy
CPU load, but what could be causing it to stutter endlessly
(until the application quits), on one frame with low/no load?
The software has stopped updating the buffer (for whatever reason),
but the hardware hasn't been told about that and continues playing
it.
Thank you, that is extremely helpful. If I'm reading this correctly,
it looks like this is not a driver problem, or a hardware problem,
but rather squarely the fault of the application which has opened the
sound device and is (or was) writing to it.
Kind of. But that's also what causes your typical xrun, right? And
/usually/ the driver will stop the device... resulting in silence, not
stuttering.
I've seen these situations cause stuttering:
1. The application is constantly writing the same data over
and over. For example, I was working on a mixer algorithm,
and sometimes I would accidentally mix in a stale buffer
with out-of date data. It did exactly this.
2. The audio interrupts have been disabled. The hardware
generates an interrupt at every period boundary. The
kernel responds to this and it ultimately causes the
userspace to be signaled to say, "we need more data."
If the interrupt is not received (or late or ignored),
then the kernel won't run it's standard code (which
also detects xruns) and the application won't write
new data. The hardware will continue to iterate over
the data in the buffers. This can be caused by /another/
driver that disables interrupts or a being caught in
a never-ending spinlock_irqsave() (which disables IRQ's).
3. It's possible in some cases to set start/stop thresholds
so that xruns never get detected. In that case, the
hardware won't stop and it'll continue to iterate on
the data in your buffer.
Approaches:
* You said it repeats a 40ms frame.
Is that the PERIOD size? If so... probably application (#1)
Is that the BUFFER size? If so... probably hardware (#2, #3)
* Can you patch the software to intercept the audio just before
writing it to hardware (snd_pcm_write*())? If so... try that
and inspect the audio. If it has the stutter... it's the
application (#1).
* Try to inspect the application using strace while it's running
normally. Try to identify what the writes to hardware look
like. (Probably an 'ioctl' call.) When the problem
happens again... inspect with strace. If there are no write's
happening... it's likely #2 or #3.[1]
-gabriel
[1] To map file descriptors to actual files... look in
/proc/<pid>/fd/. An audio output will be a file named
something like /dev/snd/pcmC0D0p
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user
