[LAU] Endlessly-stuttttttttttttttttering ALSA audio

[Gabriel M. Beddingfield]

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