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 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