Re: Lifetime of new Audio()

On Mon, Jan 31, 2011 at 4:57 PM, Adrian Bateman <adrianba@microsoft.com> wrote:
> 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.

Yup, sounds good to me.

/ Jonas

Received on Tuesday, 1 February 2011 01:48:46 UTC