Closed Bug 564734 Opened 12 years ago Closed 12 years ago
.ogg plays no sound
Our test file content/media/test/small-shot.ogg no longer plays, but our playback tests seem to pass for some reason. This is trunk only, and at least on Windows, probably on every platform. We are getting the duration correctly, and setting the current time to be equal to the duration when playback finishes, but no sound is played. This file has all its vorbis data in a single small page: $ OggIndex -d -p content/media/test/small-shot.ogg Writing output to 'content/media/test/small-shot.indexed.ogg' [V] page @0 length=58 granulepos=0 end_time=-1ms s=31415 packet_starts=1 packet_ends=1 checksum=3021601032 [V] ver=0 Ident packet [V] page @58 length=3299 granulepos=0 end_time=-1ms s=31415 packet_starts=2 packet_ends=2 checksum=2570092266 [V] ver=0 Comment packet [V] ver=0 Setup packet [V] page @3357 length=3042 granulepos=3072 end_time=276ms s=31415 packet_starts=4 packet_ends=4 checksum=2733525158 [V] sample time_ms=[0,276] granulepos=[0,3072] Vorbis/31415 index uses 82 bytes, compresses to 65 (79.2683%), duration [0,276] ms Skeleton 4.0 track with keyframe indexes uses 323 bytes, 4.80512% overhead
Summary: content/media/test/small-shot.ogg no longer plays → content/media/test/small-shot.ogg plays no sound
This is a regression from bug 531340.
On Windows, the problem is this: When we do a sa_stream_write we don't set sa_stream_t::playing to 1 unless we write a block of audio data to the hardware, and sa_stream_write buffers audio until it gets a full block of audio to write. Once AudioLoop() has finished writing all audio, we call nsAudioStream::Drain() which calls sa_stream_drain() which aborts if sa_stream_t::playing is 0. But unless AudioLoop() has written a block's worth of data to sa_stream_write, sa_stream_write won't have pushed its block to the audio hardware, and and so our drain call will abort, and no audio will have been pushed to the hardware. small-shot.ogg is so small that it doesn't even have one block's worth of audio to push to the hardware. We should probably write all unwritten buffered audio data in sa_stream_drain() on Windows. There may be different-but-similar problems with this file on other platforms.
Assignee: nobody → chris
That fix sounds good for Windows. For Linux/ALSA, I think you may need to call snd_pcm_start in drain--the same situtation may occur where the internal ALSA buffer isn't full enough to be queued for playback. You'd need to check the pcm state for SND_PCM_STATE_PREPARED before calling snd_pcm_start. I think the Mac code is correct as is.
This seems to happen on Windows only. Mac is immune, and Linux seems not to hit it (on my machine anyway).
Attachment #444550 - Flags: review?(kinetik) → review+
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.