W3C home > Mailing lists > Public > public-audio@w3.org > January to March 2014

Re: AudioBufferSourceNode.buffer how to work it.

From: Karl Tomlinson <karlt+public-audio@karlt.net>
Date: Fri, 21 Mar 2014 10:23:48 +1300
To: Chris Wilson <cwilso@google.com>
Cc: Raymond Toy <rtoy@google.com>, KeonHo Kim <keonho07.kim@samsung.com>, "public-audio\@w3.org" <public-audio@w3.org>
Message-ID: <87ior8tvh7.fsf@karlt.net>
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 Thursday, 20 March 2014 21:24:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:13 UTC