[by Martin Panter <vadmium à gmail·com>]

Retry with the same data after recovering from an underrun or other error

The palsa_callback() function seems to limit the rate it returns data, and if
a buffer of data is dropped because snd_pcm_writei() failed, the data rate is
not fast enough to keep up with ALSA and another buffer underrun occurs. This
could cause an indefinite cycle, and the audio would sound slighly choppy and
sped up. If the original data is retried, the ALSA buffer eventually tends to
become full; perhaps the rate limit is a little faster than real time.

When playback continues on to an MP3 file cued in the playlist, the MP3 seems
to be scanned before it starts playing. If the scanning takes too long, in my
case because the MP3 file is mounted with SSHFS over wifi, it causes a buffer
underrun.

The code below could also be inserted, just before the snd_pcm_writei() call,
to artificially cause an underrun a few seconds into playback:

static int n = 0;
++n;
if (n >= 200 && n < 300) {
    trace ("dropping %i\n", n);
    err = 0;
}
else
    err = snd_pcm_writei (...);

0 files changed, 0 insertions, 0 deletions