play audio independent of script completion

RESOLVED INACTIVE

Status

()

Core
Audio/Video: Playback
RESOLVED INACTIVE
7 years ago
6 days ago

People

(Reporter: jonathan chetwynd, Unassigned)

Tracking

({testcase})

Trunk
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments, 1 obsolete attachment)

7.54 KB, video/ogg
Details
365 bytes, text/html
Details
(Reporter)

Description

7 years ago
html5 audio started on onevent using javascript should start immediately.

It appears that the current implementation requires the entire script to complete, before the file begins to play.

parity Safari, Chrome, Opera

4.0b13pre(2011-03-21)
(Reporter)

Comment 1

7 years ago
Created attachment 520767 [details]
testcase
(Reporter)

Comment 2

7 years ago
Created attachment 520768 [details]
sound file
(Reporter)

Comment 3

7 years ago
Created attachment 520770 [details]
testcase
Attachment #520767 - Attachment is obsolete: true
(Reporter)

Comment 4

7 years ago
open testcase,

click on text 'play'

audio plays immediately,

wait 2 seconds, and click again,
audio plays after ~2 second delay,

wait 2 seconds, and click again,
audio plays after ~2 second delay,

URL is use-case, script is working, evaluating response from server,
however audio should play immediately.
in the use-case only Mozilla exhibits this delay.
Opera, Safari and Chrome play audio immediately.
Keywords: testcase
Calling play on a media whose currentTime is at the end of media causes it to seek to t=0 before playback begins. Our seeking implementation requires synchronous dispatch of events to the main thread in order to run nsBuiltinDecoder::SeekingStarted(). The long running JS in the test case is hogging main thread, preventing the events from running on the main thread, so delaying the start of playback.

You can work around this behaviour by seeking to t=0 and then pausing in an onended event handler, e.g.:

<audio id="atari" src="https://bugzilla.mozilla.org/attachment.cgi?id=520768" onended="event.target.currentTime=0;event.target.pause();"></audio>

For some reason pause() then seek to 0 (e.g. the opposite order as in the example above) causes infinite looping... I think that's also a bug...

It looks like the synchronous events in our seek implementation basically just dispatch "seeking" and "seeked" events, and update the readyState. I don't recall why these were dispatched synchronously, the spec doesn't specify them as being dispatched synchronously, so perhaps we should not make them synchronously dispatched.
Component: Audio/Video → Audio/Video: Playback
Mass closing do to inactivity.
Feel free to re-open if still needed.
Status: NEW → RESOLVED
Last Resolved: 6 days ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.