- 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>
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