Closed Bug 581321 Opened 15 years ago Closed 14 years ago

audio - 3.6.7 - playing multiple wav files sequentially no longer works

Categories

(Core :: Audio/Video, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

VERIFIED WORKSFORME
Tracking Status
blocking2.0 --- -

People

(Reporter: tblackburn, Unassigned)

References

Details

(Keywords: regression, Whiteboard: [needs-feedback])

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6 If I run the following html/javascript in 3.6.6 it plays the wav files sequentially. In 3.6.7 you hear nothing. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <title>serial audio example</title> <script LANGUAGE=JavaScript> var NUMBER = "012345"; var NUMBER_LENGTH = NUMBER.length; var loopCount = 1; function playNextAudio() { elem = document.getElementById("autoSerialAudio") ; if (loopCount < NUMBER_LENGTH) { elem.src = loopCount+".wav"; elem.load(); elem.play(); loopCount = loopCount + 1; } else { elem.onended = null; } return false; } </script> </head> <body <audio id="autoSerialAudio" src="0.wav" controls="true" autoplay="true" onended="playNextAudio()"> Your browser does not support the audio element. </audio> </body> </html> Reproducible: Always Steps to Reproduce: 1. open firefox 3.6.7 2. open the html above 3. audio player loads each wav file too quickly and doesn't play any of them. 4. refresh the page to do it again. Actual Results: The audio player loads each wav too quickly and doesn't play any of them. Expected Results: The audio player should load and play each wav file in turn.
Component: General → Video/Audio
Product: Firefox → Core
QA Contact: general → video.audio
blocking2.0: --- → ?
Keywords: regression
I'm not sure what other changes we've made on 1.9.2 in that timeframe other than bug 484814, so I'm guessing that's the cause. If nsWaveStateMachine fires the ended event at the time it drains the audio, the change in bug 484814 would've made the behaviour change from "firing slightly too early" to "firing much too early", which sounds like the problem here.
Here's a copy of Tony's testcase: http://flim.org/~kinetik/tests/bug581321/test.html This works fine for me in 1.9.2 on OS X.
Is this actually a bug on trunk?
I can't reproduce it at all. The testcase works fine for me on Windows 7/trunk and 1.9.2/OS X with all local files and when served via HTTP. We need more information from the reporter.
Minusing the blocking request given the current unconfirmed nature of the bug, but feel free to renominate if more information is provided.
blocking2.0: ? → -
Also works fine in a trunk nightly on Linux. Tony, can you still reproduce this? Does the testcase I created based on yours reproduce the problem for you?
I have switched to a new PC running Windows-7 and Firefox-3.6.8 and yes I still get the same problem.
Just out of interest I created a CentOS5.4 virtual machine inside my new PC, installed version 3.6.7 of Firefox and re-ran your testcase - and it works.
This is probably related to bug 586612.
Depends on: 586612
Tony, does this problem still occur for you with current Firefox 4 nightly builds?
Whiteboard: [needs-feedback]
I just installed the 64-bit nightly build from 23-Jan-2011 and it now works correctly. All wav files are played sequentially.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.