618039 - Ogg Vorbis streams sampled at 8 kHz won't play using HTML5 audio

Status: VERIFIED FIXED

(Core :: Audio/Video, defect)

Description

[Dustin C. Hatch]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101031 Firefox/3.6.12
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 (.NET CLR 3.5.30729)

I recently noticed that Firefox on Windows is no longer able to play the Ogg Vorbis streams used in one of my web applications. The streams are recordings of calls created by Asterisk and re-encoded as Ogg Vorbis. Previously, these files would play correctly using the HTML5 <audio> tag, however, this has stopped working. Firefox renders the player controls, but clicking the "play" button does nothing; the slider does not move and the time counter does not change from "0:00." No sound is played, obviously.

I traced the problem back to Firefox 3.6.7; the streams play correctly in 3.6.6 and earlier, but in 3.6.7 and later, they do not play. The issue is not present in Firefox 4.0b8pre, however.

The application itself, written in Python/Django, serves the Ogg Vorbis streams under normal circumstances, correctly responding with "206 Partial Content" in response to the "Range" requests, but I have also confirmed that the problem is manifest when sending the files directly from Apache. I have tried sending the response with the Content-Type header set to "application/ogg," "video/ogg," and "audio/ogg," experiencing the same result each time.

Other Ogg Vorbis streams play correctly, as do my files after being decoded to WAV, so I started experimenting with some different files to find out why. Here is what I discovered:

* Ogg Vorbis stream, 1 channel, 8000 Hz Sample Rate, Q3: Does not play
* Ogg Vorbis stream, 1 channel, 44100 Hz Sample Rate, Q3: Plays correctly
* WAV stream, 1 channel, 8000 Hz Sample Rate: Plays Correctly
* Ogg Vorbis stream, 2 channels, 44100 Hz Sample Rate, Q3: Plays correctly

All four streams play correctly in Firefox on Linux, as well as Google Chrome, Opera, and Firefox <= 3.6.6 on Windows.


Reproducible: Always

Actual Results:  
When pointing to a single-channel Ogg Vorbis stream sampled at 8 kHz in an HTML5 <audio> tag, the sound will not play. The data are fetched from the server and the buffer indicator on the audio control shows that the stream is ready to play, but clicking the "play" button does nothing.

Streams sampled at different rates or with two channels play correctly.

Expected Results:  
The sound should play using the <audio> tag regardless of the number of channels or sample rate.

Comment 1

[Chris Pearce [:cpearce (Not reading bugmail)]]

On trunk we're hitting bug 616800, which causes the first audio file in that testcase to stutter.

I don't know why FF 3.6.7 would be affected by this, but not FF 3.6.6. Did we update the ogg/annodex libraries in FF 3.6.7?

Comment 2

[Matthew Gregan [:kinetik]]

We changed the buffer size from 32x1kB to 10x16kB in bug 484814 around the 3.6.6/3.6.7 time frame, so possibly a regression from that (probably related to bug 586612 as well).

Comment 3

[u279076]

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8) Gecko/20100101 Firefox/4.0b8

Works for me using the above build.  The sound gets a bit choppy at times, but that is a different bug than "won't play".  Dustin, please confirm if these play for you using Firefox 4.0b8.  If they play fine on 4.0b8 and not 3.6.13, I'm thinking this bug should be resolved WONTFIX.  The choppiness I am seeing should be filed in a new bug, in this case.

Comment 4

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to comment #3)
> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8) Gecko/20100101 Firefox/4.0b8
> 
> Works for me using the above build.  The sound gets a bit choppy at times, but
> that is a different bug than "won't play".

That sounds like bug 616800.

Comment 5

[Dustin C. Hatch]

All four samples in the test case I published above play in 4.0b9. The 8 kHz Vorbis sample exhibits the behavior described in bug 616800, but does not exhibit the behavior experienced in 3.6. The other sample play correctly.

Comment 6

[Chris Pearce [:cpearce (Not reading bugmail)]]

Fixed on trunk by bug 616800.