HTML5 audio fails to play if many audio elements in play/paused first

RESOLVED WORKSFORME

Status

()

RESOLVED WORKSFORME
9 years ago
4 months ago

People

(Reporter: parente, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

9 years ago
Platform: Ubuntu Lucid Lynx
Test page: http://jsfiddle.net/eAatu/7/
Firefox v3.6.3

1) Visit the test page above.
2) Read the info in the bottom right pane.
3) Click the "Click to run test" button in the bottom right pane.

> What is the expected result?

The last audio element created and not paused should fire a start event, play, and fire an ended 
event.

> What happens instead?

More often than not, the last audio element fires a start event, then nothing. Afterward, all audio in Firefox is broken (even on other pages) until browser is restarted.

> Please provide any additional information below. 

Problem does not occur using Firefox 3.6.3 on Mac OS X 10.6.3. Problem does occur using Chrome 5.0.375.29 on Ubuntu Lucid Lynx and Mac OS X 10.6.3 (see http://code.google.com/p/chromium/issues/detail?id=44336).

This example might seem contrived, but is actually common in apps where lots of audio is 
queued and interrupted (e.g., games, long spoken menus).

Comment 1

9 years ago
Also happens on Ubuntu Karmic Koala with Firefox v3.6.3. It took 3 tries before it failed for me.

Comment 2

9 years ago
I can confirm the behavior with firefox-3.7a5pre.en-US.linux-i686 from 18 May 2010 on Ubuntu Lucid.

Comment 3

5 years ago
I get the same kind of problem on windows 7 64-bit on ff 25.0
here is my page with my music. http://jesusnjim.com/music/cakewalk.html
I only have about 7 of these audio tags. I even changed my code so that it uses the source element.
the code looks like 
  <audio controls title="Wurly Curly v5.2">
	<source src="/music/cakewalk/Wurly-Curly-v5.2-256.mp3" type="audio/mpeg">
	<embed src="/music/cakewalk/Wurly-Curly-v5.2-256.mp3" type="audio/mpeg" width="400">
  </audio>
The Windows/MP3 bug is is bug 882537. This will be fixed when we switch MP3 decoding to use DirectShow instead of Windows Media Foundation. That will happen once bug 918135 is fixed. This sounds like a different issue to the bug as filed here, which is Linux specific I think.
Component: Audio/Video → Audio/Video: Playback
Status: NEW → RESOLVED
Last Resolved: 4 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.