a52: can't fill input buffer if can't empty output buffer. Stuttering sound in XBMC. [patch]

In pcm_a52.c, write_out_pending can return -EAGAIN if the downstream buffer has no free space. When called from a52_transfer-->fill_data, the -EAGAIN causes the entire call to abort with -EAGAIN, making it look like a52's input buffer is full, when really there's plenty space. Whether a frame can be accepted or not does not depend on state of the the output buffer, but only on the free space in the input buffer, which is checked right at the start of the function.

Whilst it's nice to empty the output buffer so the new frames can be processed, failure to do so does not prevent accepting frames, so such a failure should be ignored to allow the incoming frames to be accepted.

Newer versions of XBMC (Frodo onwards) have a re-written audio engine that triggers this bug, every three playback-minutes or so. Despite being written to use asynchronous mode, the new audio engine really doesn't like getting back large numbers of EAGAINs, and repeatedly reinitialises the PCM on the assumption that it is broken. The problem is made worse by XBMC immediately retrying the call when it can only succeed after the hardware has consumed another AC3 packet.

Without patch: XBMC playback frequently interrupted with judders, motorboating, and video pausing while sound is restarted
With patch: occasional audio artefacts, video playback unaffected by pausing

I don't have the resources to test against upstream or unstable, though the source code appears to do the same thing. ALSA's bugtracker appears to be down.

----------

Ubuntu version-
Description: Ubuntu 12.04.3 LTS
Release: 12.04

Package version-
alsa-plugins_1.0.25-1ubuntu1