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)
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.
Updated•15 years ago
|
Component: General → Video/Audio
Product: Firefox → Core
QA Contact: general → video.audio
Updated•15 years ago
|
blocking2.0: --- → ?
Keywords: regression
Comment 1•15 years ago
|
||
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.
Comment 2•15 years ago
|
||
Drain is called before firing the ended event: http://mxr.mozilla.org/mozilla1.9.2/source/content/media/wave/nsWaveDecoder.cpp#730
Comment 3•15 years ago
|
||
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?
Comment 5•15 years ago
|
||
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: ? → -
Comment 7•14 years ago
|
||
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?
Reporter | ||
Comment 8•14 years ago
|
||
I have switched to a new PC running Windows-7 and Firefox-3.6.8 and yes I still get the same problem.
Reporter | ||
Comment 9•14 years ago
|
||
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.
Comment 11•14 years ago
|
||
Tony, does this problem still occur for you with current Firefox 4 nightly builds?
Whiteboard: [needs-feedback]
Reporter | ||
Comment 12•14 years ago
|
||
I just installed the 64-bit nightly build from 23-Jan-2011 and it now works correctly.
All wav files are played sequentially.
Updated•14 years ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•