- From: Karl Tomlinson <karlt+public-audio@karlt.net>
- Date: Wed, 22 Jan 2014 14:40:38 +1300
- To: Raymond Toy <rtoy@google.com>
- Cc: "public-audio\@w3.org" <public-audio@w3.org>
Raymond Toy writes:
> Consider this:
>
> c = new webkitAudioContex();
> s = c.createBufferSource();
> s.connect(c,destination);
> c.decodeAudioData(data, function () { s.buffer = data });
> s.start(0);
>
> Let's say decodeAudioData takes 10 sec to decode. What is supposed to
> happen here?
Reading the current spec, I would have expected/guessed start()
would set the start time to the time at the call to start(). When
the buffer is set later, it would start playing at an offset equal
to the elapsed time since start() was called. If this
interpretation were used, some other means would be required to
defeat iOS user interaction requirements: setting playbackRate to
0 temporarily, perhaps. Requiring the UA to integrate
playbackRate even while the there is no buffer may be a little
awkward.
Gecko, however, seems to match Webkit and Blink's old behaviour of
starting playback from the beginning of the buffer (at the time
when the buffer is set).
Received on Wednesday, 22 January 2014 01:41:19 UTC