Comment 38 for bug 450684

The symptoms I'm seeing are these: when resuming playback (after buffering or a user-initiated pause), PlayFrame() expects the audio clock to reach the presentation time of the current frame, so it poll-waits in the loop at http://hg.mozilla.org/mozilla-central/file/c99505cf0eff/content/media/ogg/nsOggDecoder.cpp#l930. The repeated calls to PlayAudio() write any buffered audio we have (on the frame, or stored in mBufferOverflow on the nsAudioStream instance) to be written to the ALSA backend. At this stage, we've written out all of the audio data that we have bufferd, the audio backend is in the "playing" state, and the audio clock never advances to the current frame time.

The problem seems to be that PulseAudio-backed ALSA installations require a minimum amount of buffer filling before playback actually begins (and starts ticking the audio clock), and we're not writing enough audio data out to meet this minimum fill level. Increasing OGGPLAY_AUDIO_OFFSET (e.g. from 250ms to 500ms) or reducing the latency parameter passed to snd_pcm_set_params (from 500ms to 200ms) seems to solve this problem. Reducing the requested latency is probably a good short term fix as it makes some sense that we'd need to write more than 250ms of audio to satisfy a requested buffering/latency target of 500ms. A more correct fix might be to work out if we can query the minimum buffer fill level and ensure that we always write at least that much audio data before expecting the audio clock to resume ticking.