RE: AudioBufferSourceNode.buffer how to work it.

@Chris.

This is current implementation in engine side by internal my test sample.


1. When JS calls start(0) without setting a buffer.
Blink/Webkit -> Immediately SourceNode's playback state changed to
FINISHED_STATE, no DOMexception.
Gecko -> Just slience, no DOMexception.

2. When JS calls start(0) with setting 'null' javacript object.
Blink/Webkit -> DOMexception. "Cannot set to null"
Gecko -> Just slience, no DOMexception.

3. After 1 or 2, Then set a buffer after calling start(0)
Blink/Webkit -> Previsouly DOMexception causes error, no sound.
Gecko -> Playing from beginning of buffer.

Br,
KeonHo

-----Original Message-----
From: Karl Tomlinson [mailto:karlt+public-audio@karlt.net] 
Sent: Friday, March 21, 2014 6:24 AM
To: Chris Wilson
Cc: Raymond Toy; KeonHo Kim; public-audio@w3.org
Subject: Re: AudioBufferSourceNode.buffer how to work it.

Chris Wilson writes:

> I'm not allergic to defining this some other way; however, I do think 
> we need to very carefully define it.  Primarily, I'm interested in 
> what happens when you call start(0) with no buffer, and at some later 
> point set the buffer.

The options I can imagine are:

1) The start time is determined when start() is called.

   For the start(0) case, when the buffer starts playing, the
   position in the buffer from where playback begins has an
   additional offset due to the elapsed time since start(0)
   was called.

   This requires the implementation to integrate playbackRate even
   over the period where there is no buffer.

2) The start time is determined at the later of the times when the
   buffer is set and start is called (regardless of order).

   The position in the buffer from where playback begins is always
   the value of "offset" passed to start().

   Gecko, Blink, and Webkit currently implement this option.

If we consider a null buffer to have a zero sampleRate, and think of buffer
position in frames rather than time, then the additional offset in option 1
is zero frames and 1 is equivalent to 2.

If we think of buffer position in time (seconds), then the options differ.

> On Mon, Mar 17, 2014 at 9:18 PM, Karl Tomlinson <
> karlt+public-audio@karlt.net> wrote:
>
>> The spec currently doesn't require any particular ordering of setting 
>> the buffer and calling start(), and so introducing a new requirement 
>> would affect backward compatibility.
>>
>> This includes the issue identified in 
>> http://lists.w3.org/Archives/Public/public-audio/2014JanMar/0063.html
>>
>> Requiring all changes (except stop()) to the AudioBufferSourceNode to 
>> be made before calling start() would certainly make things simpler 
>> for implementations, but IMO we should have a stronger reason before 
>> making breaking changes.
>>
>> Chris Wilson writes:
>>
>> > I actually think start() should throw if the buffer is null.
>> >
>> >
>> > On Mon, Mar 17, 2014 at 2:50 PM, Raymond Toy <rtoy@google.com> wrote:
>> >
>> >> I also agree. But note that case 1:
>> >>
>> >> < case1 >
>> >> sourcenode.buffer = null;
>> >> sourcenode.start(0); // mute
>> >> ...
>> >> sourcenode.buffer = meaningfulbuffer; // sound
>> >>
>> >> I personally feel this should not be allowed either.

Received on Friday, 21 March 2014 01:52:50 UTC