On 10/26/2012 03:02 AM, Ken Restivo wrote:
Kind of. But that's also what causes your typical xrun, right? And
/usually/ the driver will stop the device... resulting in silence, not
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.
* 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
* 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.
 To map file descriptors to actual files... look in
/proc//fd/. An audio output will be a file named
something like /dev/snd/pcmC0D0p
Linux-audio-user mailing list