RE: Lifetime of new Audio()

On Sunday, January 30, 2011 9:53 PM, Adrian Bateman wrote:
> On Sunday, January 30, 2011 8:37 PM, Chris Double wrote:
> > On Mon, Jan 31, 2011 at 2:52 PM, Adrian Bateman
> > <adrianba@microsoft.com>
> > wrote:
> > > Ignoring for now the timing issue of how quickly the play() actually
> > > has enough content to start playing, after the function returns
> > > there is no reference to the Audio object. Is the fact that the
> > > object is playing enough to pin it in memory? Otherwise the GC could
> > > collect the object and stop the playing. I scanned the media section
> > > of the spec but couldn't see where it defines this behaviour one way or
> the other.
> >
> > This is mentioned in the media section immediately after talking about
> > 'playback rate'
> >
> > "Media elements that are potentially playing while not in a Document
> > must not play any video, but should play any audio component. Media
> > elements must not stop playing just because all references to them
> > have been removed; only once a media element to which no references
> > exist has reached a point where no further audio remains to be played
> > for that element (e.g. because the element is paused, or because the
> > end of the clip has been reached, or because its playbackRate is 0.0)
> > may the element be garbage collected."
> 
> Thanks Chris - that was the part I missed.

We've analysed this section of the spec.
http://dev.w3.org/html5/spec/video.html#media-playback

This uses the phrase "potentially playing", which is defined as:

"A media element is said to be potentially playing when its paused
 attribute is false, the readyState attribute is either HAVE_FUTURE_DATA
 or HAVE_ENOUGH_DATA, the element has not ended playback, playback has
 not stopped due to errors, and the element has not paused for user
 interaction."
http://dev.w3.org/html5/spec/video.html#potentially-playing

The problem with this is that there is still a race between the GC and the
network in the example that I gave originally:

function playAudio() {
  var a = new Audio("http://www.example.com/music");
  a.play();
}

This means that after the function exits, the behaviour will vary depending
upon whether the GC fires before or after readyState gets to HAVE_FUTURE_DATA.
I think this goes against what Jonas was saying.

On Sunday, January 30, 2011 7:44 PM, Jonas Sicking wrote:
> So in this case I think yes, playing should ensure that the object
> doesn't get GCed. Or rather, GC should not stop the sound from
> playing. Technically you could push the sound file to the sound
> subsystem and then destroy the element as that would be
> indistinguishable for everyone. At least as long as no event handlers
> are attached to the element.

We're considering removing the readyState check from potentially playing
in our implementation for this specific scenario so that the element will
only be available to be collected on error, when paused, at the end of the
media, or if somehow stopped by user interaction.

If you agree I will file a bug requesting this change.

Thanks,

Adrian.

Received on Tuesday, 1 February 2011 00:58:13 UTC