Support nullable buffer for AudioBufferSourceNode.

Support nullable buffer for AudioBufferSourceNode.

According to W3C specification about Web Audio API, it can be set null.
http://www.w3.org/TR/webaudio/#AudioBufferSourceNode-section

"The number of channels of the output always equals the number of channels of the AudioBuffer
assigned to the .buffer attribute, or is one channel of silence if .buffer is NULL."

This feature can make AudioBufferSource mute without stop() and gainNode.

BUG=350768

[KhNo, 2014-03-10 08:57:30]

kbr@chromium.org: Please review changes in 

rtoy@chromium.org: Please review changes in 

Please review this patch.
I have uploaded test sample in BUG=350768.

Firefox worked fine. But blink was not.

[Raymond Toy, 2014-03-10 17:53:34]

On 2014/03/10 08:57:30, KhNo wrote:
> kbr@chromium.org: Please review changes in 
> 
> rtoy@chromium.org: Please review changes in 
> 
> Please review this patch.
> I have uploaded test sample in BUG=350768.
> 
> Firefox worked fine. But blink was not.

This is rather confusing to me. When an AudioBufferSourceNode is created, the
buffer attribute is null, and no audio is produced (or silence is produced). You
are proposing that if a buffer was set and now it is set to null, silence is
produced.

It's not clear to me that setting the buffer more than once is allowed
(https://github.com/WebAudio/web-audio-api/issues/288), and since stop() can be
called more than once now, the same effect can be had by just calling stop().

Please clarify this with the W3C audio group.

[KhNo, 2014-03-10 18:12:10]

On 2014/03/10 17:53:34, Raymond Toy wrote:
> On 2014/03/10 08:57:30, KhNo wrote:
> > kbr@chromium.org: Please review changes in 
> > 
> > rtoy@chromium.org: Please review changes in 
> > 
> > Please review this patch.
> > I have uploaded test sample in BUG=350768.
> > 
> > Firefox worked fine. But blink was not.
> 
> This is rather confusing to me. When an AudioBufferSourceNode is created, the
> buffer attribute is null, and no audio is produced (or silence is produced).
You
> are proposing that if a buffer was set and now it is set to null, silence is
> produced.
> 
> It's not clear to me that setting the buffer more than once is allowed
> (https://github.com/WebAudio/web-audio-api/issues/288), and since stop() can
be
> called more than once now, the same effect can be had by just calling stop().
> 
> Please clarify this with the W3C audio group.

There is no restriction that setBuffer can be called only once.
I think It can call several times. 

According to specification, start() and stop() method can be called only once.
http://www.w3.org/TR/webaudio/#AudioBufferSourceNode
"start may only be called one time and must be called before stop is called or
an INVALID_STATE_ERR exception MUST be thrown."
"stop must only be called one time and only after a call to start or stop, or an
INVALID_STATE_ERR exception MUST be thrown."

So, original source code is not allowed call several times about start() and
stop() methods.

Actually there was FIXME about nullable buffer supporting. If setBuffer is
called during playing previous buffer, 
it should be replaced and working with new buffer. The original source code
works as my comment.

This feature can be AudioBufferSourceNode muted without changing gain or call
stop().
After stop(), JS developer has to create new AudioBufferSourceNode and set all
values again.

I attached sample file in BUG=350768. Firefox browser works as specification
expected.

Please check again. I think it gives many thing to JS developer.

[KhNo, 2014-03-10 18:12:12]

On 2014/03/10 17:53:34, Raymond Toy wrote:
> On 2014/03/10 08:57:30, KhNo wrote:
> > kbr@chromium.org: Please review changes in 
> > 
> > rtoy@chromium.org: Please review changes in 
> > 
> > Please review this patch.
> > I have uploaded test sample in BUG=350768.
> > 
> > Firefox worked fine. But blink was not.
> 
> This is rather confusing to me. When an AudioBufferSourceNode is created, the
> buffer attribute is null, and no audio is produced (or silence is produced).
You
> are proposing that if a buffer was set and now it is set to null, silence is
> produced.
> 
> It's not clear to me that setting the buffer more than once is allowed
> (https://github.com/WebAudio/web-audio-api/issues/288), and since stop() can
be
> called more than once now, the same effect can be had by just calling stop().
> 
> Please clarify this with the W3C audio group.

There is no restriction that setBuffer can be called only once.
I think It can call several times. 

According to specification, start() and stop() method can be called only once.
http://www.w3.org/TR/webaudio/#AudioBufferSourceNode
"start may only be called one time and must be called before stop is called or
an INVALID_STATE_ERR exception MUST be thrown."
"stop must only be called one time and only after a call to start or stop, or an
INVALID_STATE_ERR exception MUST be thrown."

So, original source code is not allowed call several times about start() and
stop() methods.

Actually there was FIXME about nullable buffer supporting. If setBuffer is
called during playing previous buffer, 
it should be replaced and working with new buffer. The original source code
works as my comment.

This feature can be AudioBufferSourceNode muted without changing gain or call
stop().
After stop(), JS developer has to create new AudioBufferSourceNode and set all
values again.

I attached sample file in BUG=350768. Firefox browser works as specification
expected.

Please check again. I think it gives many thing to JS developer.

[Raymond Toy, 2014-03-10 18:36:04]

On 2014/03/10 18:12:12, KhNo wrote:
> On 2014/03/10 17:53:34, Raymond Toy wrote:
> > On 2014/03/10 08:57:30, KhNo wrote:
> > > kbr@chromium.org: Please review changes in 
> > > 
> > > rtoy@chromium.org: Please review changes in 
> > > 
> > > Please review this patch.
> > > I have uploaded test sample in BUG=350768.
> > > 
> > > Firefox worked fine. But blink was not.
> > 
> > This is rather confusing to me. When an AudioBufferSourceNode is created,
the
> > buffer attribute is null, and no audio is produced (or silence is produced).
> You
> > are proposing that if a buffer was set and now it is set to null, silence is
> > produced.
> > 
> > It's not clear to me that setting the buffer more than once is allowed
> > (https://github.com/WebAudio/web-audio-api/issues/288), and since stop() can
> be
> > called more than once now, the same effect can be had by just calling
stop().
> > 
> > Please clarify this with the W3C audio group.
> 
> There is no restriction that setBuffer can be called only once.
> I think It can call several times. 

Read the linked issue. It's unclear whether the buffer can be set more than
once. It's currently allowed but I tend to think it shouldn't be because you
have no control over when the buffer will actually start, if the original buffer
has already been start()ed. This goes against WebAudio's sample accurate timing.
> 
> According to specification, start() and stop() method can be called only once.
> http://www.w3.org/TR/webaudio/#AudioBufferSourceNode
> "start may only be called one time and must be called before stop is called or
> an INVALID_STATE_ERR exception MUST be thrown."
> "stop must only be called one time and only after a call to start or stop, or
an
> INVALID_STATE_ERR exception MUST be thrown."

That link is a bit out-of-date.  Use http://webaudio.github.io/web-audio-api/ if
you want to follow the latest version.  stop() can be called more than once.

> 
> So, original source code is not allowed call several times about start() and
> stop() methods.
> 
> Actually there was FIXME about nullable buffer supporting. If setBuffer is
> called during playing previous buffer, 
> it should be replaced and working with new buffer. The original source code
> works as my comment.
> 
> This feature can be AudioBufferSourceNode muted without changing gain or call
> stop().
> After stop(), JS developer has to create new AudioBufferSourceNode and set all
> values again.
> 
> I attached sample file in BUG=350768. Firefox browser works as specification
> expected.
> 
> Please check again. I think it gives many thing to JS developer.

[KhNo, 2014-03-10 19:47:31]

On 2014/03/10 18:36:04, Raymond Toy wrote:
> On 2014/03/10 18:12:12, KhNo wrote:
> > On 2014/03/10 17:53:34, Raymond Toy wrote:
> > > On 2014/03/10 08:57:30, KhNo wrote:
> > > > kbr@chromium.org: Please review changes in 
> > > > 
> > > > rtoy@chromium.org: Please review changes in 
> > > > 
> > > > Please review this patch.
> > > > I have uploaded test sample in BUG=350768.
> > > > 
> > > > Firefox worked fine. But blink was not.
> > > 
> > > This is rather confusing to me. When an AudioBufferSourceNode is created,
> the
> > > buffer attribute is null, and no audio is produced (or silence is
produced).
> > You
> > > are proposing that if a buffer was set and now it is set to null, silence
is
> > > produced.
> > > 
> > > It's not clear to me that setting the buffer more than once is allowed
> > > (https://github.com/WebAudio/web-audio-api/issues/288), and since stop()
can
> > be
> > > called more than once now, the same effect can be had by just calling
> stop().
> > > 
> > > Please clarify this with the W3C audio group.
> > 
> > There is no restriction that setBuffer can be called only once.
> > I think It can call several times. 
> 
> Read the linked issue. It's unclear whether the buffer can be set more than
> once. It's currently allowed but I tend to think it shouldn't be because you
> have no control over when the buffer will actually start, if the original
buffer
> has already been start()ed. This goes against WebAudio's sample accurate
timing.

Yes, there is a timing issue when it should be started if I understand that
article correctly.
It seems to be no way to re use same AudioBufferSourceNode.
But, as one of reply, creation of new AudioBufferSourceNode might be one of
solution.

I believe if there is setBuffer dying playing already start()ed, stop rendering
old buffer and start rendering new buffer or start silence if it is null.
If I explain use case of nullable buffer,
MediaElementSourceNode, MediaStreamSourceNode can be null buffer if it needs
buffering when it is not enough to play.
At that time, it can be no more render sound after buffering has once. 

Could you consider this patch again?

> > 
> > According to specification, start() and stop() method can be called only
once.
> > http://www.w3.org/TR/webaudio/#AudioBufferSourceNode
> > "start may only be called one time and must be called before stop is called
or
> > an INVALID_STATE_ERR exception MUST be thrown."
> > "stop must only be called one time and only after a call to start or stop,
or
> an
> > INVALID_STATE_ERR exception MUST be thrown."
> 
> That link is a bit out-of-date.  Use http://webaudio.github.io/web-audio-api/
if
> you want to follow the latest version.  stop() can be called more than once.
> 

http://webaudio.github.io/web-audio-api

I checked it. There is still mentioning about it in the table 2.9.2 Methods
"when" .
The specification represents start() can not be called after calling stop().
start() should be called before calling stop().
It doesn't means stop() can called several time.
So, JS developer should create new buffer after stop(). It can not be used
anymore actually after calling stop once.
In the specification, there is still nullable buffer.
I understand what you are raising issue to specification. 
However, I believe that setBuffer should work with new buffer and rendering
immediately if it was started.

> > 
> > So, original source code is not allowed call several times about start() and
> > stop() methods.
> > 
> > Actually there was FIXME about nullable buffer supporting. If setBuffer is
> > called during playing previous buffer, 
> > it should be replaced and working with new buffer. The original source code
> > works as my comment.
> > 
> > This feature can be AudioBufferSourceNode muted without changing gain or
call
> > stop().
> > After stop(), JS developer has to create new AudioBufferSourceNode and set
all
> > values again.
> > 
> > I attached sample file in BUG=350768. Firefox browser works as specification
> > expected.
> > 
> > Please check again. I think it gives many thing to JS developer.

[KhNo, 2014-03-10 20:02:55]

On 2014/03/10 19:47:31, KhNo wrote:
> On 2014/03/10 18:36:04, Raymond Toy wrote:
> > On 2014/03/10 18:12:12, KhNo wrote:
> > > On 2014/03/10 17:53:34, Raymond Toy wrote:
> > > > On 2014/03/10 08:57:30, KhNo wrote:
> > > > > kbr@chromium.org: Please review changes in 
> > > > > 
> > > > > rtoy@chromium.org: Please review changes in 
> > > > > 
> > > > > Please review this patch.
> > > > > I have uploaded test sample in BUG=350768.
> > > > > 
> > > > > Firefox worked fine. But blink was not.
> > > > 
> > > > This is rather confusing to me. When an AudioBufferSourceNode is
created,
> > the
> > > > buffer attribute is null, and no audio is produced (or silence is
> produced).
> > > You
> > > > are proposing that if a buffer was set and now it is set to null,
silence
> is
> > > > produced.
> > > > 
> > > > It's not clear to me that setting the buffer more than once is allowed
> > > > (https://github.com/WebAudio/web-audio-api/issues/288), and since stop()
> can
> > > be
> > > > called more than once now, the same effect can be had by just calling
> > stop().
> > > > 
> > > > Please clarify this with the W3C audio group.
> > > 
> > > There is no restriction that setBuffer can be called only once.
> > > I think It can call several times. 
> > 
> > Read the linked issue. It's unclear whether the buffer can be set more than
> > once. It's currently allowed but I tend to think it shouldn't be because you
> > have no control over when the buffer will actually start, if the original
> buffer
> > has already been start()ed. This goes against WebAudio's sample accurate
> timing.
> 
> Yes, there is a timing issue when it should be started if I understand that
> article correctly.
> It seems to be no way to re use same AudioBufferSourceNode.
> But, as one of reply, creation of new AudioBufferSourceNode might be one of
> solution.
> 
> I believe if there is setBuffer dying playing already start()ed, stop
rendering
> old buffer and start rendering new buffer or start silence if it is null.
> If I explain use case of nullable buffer,
> MediaElementSourceNode, MediaStreamSourceNode can be null buffer if it needs
> buffering when it is not enough to play.
> At that time, it can be no more render sound after buffering has once. 
> 
> Could you consider this patch again?
> 
> > > 
> > > According to specification, start() and stop() method can be called only
> once.
> > > http://www.w3.org/TR/webaudio/#AudioBufferSourceNode
> > > "start may only be called one time and must be called before stop is
called
> or
> > > an INVALID_STATE_ERR exception MUST be thrown."
> > > "stop must only be called one time and only after a call to start or stop,
> or
> > an
> > > INVALID_STATE_ERR exception MUST be thrown."
> > 
> > That link is a bit out-of-date.  Use
http://webaudio.github.io/web-audio-api/
> if
> > you want to follow the latest version.  stop() can be called more than once.
> > 
> 
> http://webaudio.github.io/web-audio-api
> 
> I checked it. There is still mentioning about it in the table 2.9.2 Methods
> "when" .
> The specification represents start() can not be called after calling stop().
> start() should be called before calling stop().
> It doesn't means stop() can called several time.
> So, JS developer should create new buffer after stop(). It can not be used
> anymore actually after calling stop once.
> In the specification, there is still nullable buffer.
> I understand what you are raising issue to specification. 
> However, I believe that setBuffer should work with new buffer and rendering
> immediately if it was started.
> 
> > > 
> > > So, original source code is not allowed call several times about start()
and
> > > stop() methods.
> > > 
> > > Actually there was FIXME about nullable buffer supporting. If setBuffer is
> > > called during playing previous buffer, 
> > > it should be replaced and working with new buffer. The original source
code
> > > works as my comment.
> > > 
> > > This feature can be AudioBufferSourceNode muted without changing gain or
> call
> > > stop().
> > > After stop(), JS developer has to create new AudioBufferSourceNode and set
> all
> > > values again.
> > > 
> > > I attached sample file in BUG=350768. Firefox browser works as
specification
> > > expected.
> > > 
> > > Please check again. I think it gives many thing to JS developer.

Sorry about no more quick response. Korea is almost 5 am. I need to go to the
bed. :)
I'm really happy having this kind of discussion about web audio. Actually there
are no many engineers around me.
Thank you always. I'm exciting contributing of patch about web audio.

[Raymond Toy, 2014-03-10 20:23:56]

On 2014/03/10 20:02:55, KhNo wrote:
> On 2014/03/10 19:47:31, KhNo wrote:
> > On 2014/03/10 18:36:04, Raymond Toy wrote:
> > > On 2014/03/10 18:12:12, KhNo wrote:
> > > > On 2014/03/10 17:53:34, Raymond Toy wrote:
> > > > > On 2014/03/10 08:57:30, KhNo wrote:
> > > > > > kbr@chromium.org: Please review changes in 
> > > > > > 
> > > > > > rtoy@chromium.org: Please review changes in 
> > > > > > 
> > > > > > Please review this patch.
> > > > > > I have uploaded test sample in BUG=350768.
> > > > > > 
> > > > > > Firefox worked fine. But blink was not.
> > > > > 
> > > > > This is rather confusing to me. When an AudioBufferSourceNode is
> created,
> > > the
> > > > > buffer attribute is null, and no audio is produced (or silence is
> > produced).
> > > > You
> > > > > are proposing that if a buffer was set and now it is set to null,
> silence
> > is
> > > > > produced.
> > > > > 
> > > > > It's not clear to me that setting the buffer more than once is allowed
> > > > > (https://github.com/WebAudio/web-audio-api/issues/288), and since
stop()
> > can
> > > > be
> > > > > called more than once now, the same effect can be had by just calling
> > > stop().
> > > > > 
> > > > > Please clarify this with the W3C audio group.
> > > > 
> > > > There is no restriction that setBuffer can be called only once.
> > > > I think It can call several times. 
> > > 
> > > Read the linked issue. It's unclear whether the buffer can be set more
than
> > > once. It's currently allowed but I tend to think it shouldn't be because
you
> > > have no control over when the buffer will actually start, if the original
> > buffer
> > > has already been start()ed. This goes against WebAudio's sample accurate
> > timing.
> > 
> > Yes, there is a timing issue when it should be started if I understand that
> > article correctly.
> > It seems to be no way to re use same AudioBufferSourceNode.
> > But, as one of reply, creation of new AudioBufferSourceNode might be one of
> > solution.

Yes, I think this was Chris Roger's original intent.  A source node can be used
exactly once. If you want to play the sound again, create a new source node with
the same buffer as before.

> > 
> > I believe if there is setBuffer dying playing already start()ed, stop
> rendering
> > old buffer and start rendering new buffer or start silence if it is null.

Yes, this is exactly the question I raised to the W3C group. Can you set the
buffer again after it's already been set to a non-null value?

Except, I don't understand what you mean by "setBuffer dying playing already
started()ed".

> > If I explain use case of nullable buffer,
> > MediaElementSourceNode, MediaStreamSourceNode can be null buffer if it needs
> > buffering when it is not enough to play.
> > At that time, it can be no more render sound after buffering has once. 
> > 
> > Could you consider this patch again?

I'm not immediately rejecting this patch. I just want clarification (from W3C)
on how this is exactly supposed to work before proceeding. I don't want to
commit a change only to find out that this was the wrong thing to do. I just
want to fix it once and once only.

> > 
> > > > 
> > > > According to specification, start() and stop() method can be called only
> > once.
> > > > http://www.w3.org/TR/webaudio/#AudioBufferSourceNode
> > > > "start may only be called one time and must be called before stop is
> called
> > or
> > > > an INVALID_STATE_ERR exception MUST be thrown."
> > > > "stop must only be called one time and only after a call to start or
stop,
> > or
> > > an
> > > > INVALID_STATE_ERR exception MUST be thrown."
> > > 
> > > That link is a bit out-of-date.  Use
> http://webaudio.github.io/web-audio-api/
> > if
> > > you want to follow the latest version.  stop() can be called more than
once.
> > > 
> > 
> > http://webaudio.github.io/web-audio-api
> > 
> > I checked it. There is still mentioning about it in the table 2.9.2 Methods
> > "when" .
> > The specification represents start() can not be called after calling stop().
> > start() should be called before calling stop().
> > It doesn't means stop() can called several time.

Oh, I think that is a mistake. The description for the stop method shows that
stop can be called more than once. The actual discussion on the W3C is here: 
https://github.com/WebAudio/web-audio-api/issues/15. I'll file an issue about
the text.


> > So, JS developer should create new buffer after stop(). It can not be used
> > anymore actually after calling stop once.
> > In the specification, there is still nullable buffer.
> > I understand what you are raising issue to specification. 
> > However, I believe that setBuffer should work with new buffer and rendering
> > immediately if it was started.

The problem is that "rendering immediately" is not clear. There is some time
between the JS call to set the buffer and when it actually starts rendering. 
This could be on the order of many 10s of milliseconds or more if GC happens
just after the JS call, but before it makes its way to the audio thread.

> > 
> > > > 
> > > > So, original source code is not allowed call several times about start()
> and
> > > > stop() methods.
> > > > 
> > > > Actually there was FIXME about nullable buffer supporting. If setBuffer
is
> > > > called during playing previous buffer, 
> > > > it should be replaced and working with new buffer. The original source
> code
> > > > works as my comment.
> > > > 
> > > > This feature can be AudioBufferSourceNode muted without changing gain or
> > call
> > > > stop().
> > > > After stop(), JS developer has to create new AudioBufferSourceNode and
set
> > all
> > > > values again.
> > > > 
> > > > I attached sample file in BUG=350768. Firefox browser works as
> specification
> > > > expected.
> > > > 
> > > > Please check again. I think it gives many thing to JS developer.
> 
> Sorry about no more quick response. Korea is almost 5 am. I need to go to the
> bed. :)
> I'm really happy having this kind of discussion about web audio. Actually
there
> are no many engineers around me.
> Thank you always. I'm exciting contributing of patch about web audio.

No worries. I don't expect answers from you after a normal workday. And it's
always better to have discussions when a participant is not suffering from lack
of sleep!

I appreciate all of your CLs.  Makes me really think about how things are
supposed to work and that's good.

[KhNo, 2014-03-11 06:25:05]

On 2014/03/10 20:23:56, Raymond Toy wrote:
> On 2014/03/10 20:02:55, KhNo wrote:
> > On 2014/03/10 19:47:31, KhNo wrote:
> > > On 2014/03/10 18:36:04, Raymond Toy wrote:
> > > > On 2014/03/10 18:12:12, KhNo wrote:
> > > > > On 2014/03/10 17:53:34, Raymond Toy wrote:
> > > > > > On 2014/03/10 08:57:30, KhNo wrote:
> > > > > > > kbr@chromium.org: Please review changes in 
> > > > > > > 
> > > > > > > rtoy@chromium.org: Please review changes in 
> > > > > > > 
> > > > > > > Please review this patch.
> > > > > > > I have uploaded test sample in BUG=350768.
> > > > > > > 
> > > > > > > Firefox worked fine. But blink was not.
> > > > > > 
> > > > > > This is rather confusing to me. When an AudioBufferSourceNode is
> > created,
> > > > the
> > > > > > buffer attribute is null, and no audio is produced (or silence is
> > > produced).
> > > > > You
> > > > > > are proposing that if a buffer was set and now it is set to null,
> > silence
> > > is
> > > > > > produced.
> > > > > > 
> > > > > > It's not clear to me that setting the buffer more than once is
allowed
> > > > > > (https://github.com/WebAudio/web-audio-api/issues/288), and since
> stop()
> > > can
> > > > > be
> > > > > > called more than once now, the same effect can be had by just
calling
> > > > stop().
> > > > > > 
> > > > > > Please clarify this with the W3C audio group.
> > > > > 
> > > > > There is no restriction that setBuffer can be called only once.
> > > > > I think It can call several times. 
> > > > 
> > > > Read the linked issue. It's unclear whether the buffer can be set more
> than
> > > > once. It's currently allowed but I tend to think it shouldn't be because
> you
> > > > have no control over when the buffer will actually start, if the
original
> > > buffer
> > > > has already been start()ed. This goes against WebAudio's sample accurate
> > > timing.
> > > 
> > > Yes, there is a timing issue when it should be started if I understand
that
> > > article correctly.
> > > It seems to be no way to re use same AudioBufferSourceNode.
> > > But, as one of reply, creation of new AudioBufferSourceNode might be one
of
> > > solution.
> 
> Yes, I think this was Chris Roger's original intent.  A source node can be
used
> exactly once. If you want to play the sound again, create a new source node
with
> the same buffer as before.
> 

I agreee with you. That is exactly webaudio context even if JS developer is
little bit unconvience.

> > > 
> > > I believe if there is setBuffer dying playing already start()ed, stop
> > rendering
> > > old buffer and start rendering new buffer or start silence if it is null.
> 
> Yes, this is exactly the question I raised to the W3C group. Can you set the
> buffer again after it's already been set to a non-null value?
> 

Current implementation works to set new buffer again after it is already been
set.
In addtion, it can be set during playing with old buffer as well. Sound just
changed with new buffer.
Only nullable buffer can not be set currently neither it is first time nor
second time when there is setbuffer with non-null buffer..

> Except, I don't understand what you mean by "setBuffer dying playing already
> started()ed".
> 

Sorry, there was misstypo. "I believe if there is setBuffer during playing
prevous buffer already start()ed.


> > > If I explain use case of nullable buffer,
> > > MediaElementSourceNode, MediaStreamSourceNode can be null buffer if it
needs
> > > buffering when it is not enough to play.
> > > At that time, it can be no more render sound after buffering has once. 
> > > 
> > > Could you consider this patch again?
> 
> I'm not immediately rejecting this patch. I just want clarification (from W3C)
> on how this is exactly supposed to work before proceeding. I don't want to
> commit a change only to find out that this was the wrong thing to do. I just
> want to fix it once and once only.
> 
> > > 
> > > > > 
> > > > > According to specification, start() and stop() method can be called
only
> > > once.
> > > > > http://www.w3.org/TR/webaudio/#AudioBufferSourceNode
> > > > > "start may only be called one time and must be called before stop is
> > called
> > > or
> > > > > an INVALID_STATE_ERR exception MUST be thrown."
> > > > > "stop must only be called one time and only after a call to start or
> stop,
> > > or
> > > > an
> > > > > INVALID_STATE_ERR exception MUST be thrown."
> > > > 
> > > > That link is a bit out-of-date.  Use
> > http://webaudio.github.io/web-audio-api/
> > > if
> > > > you want to follow the latest version.  stop() can be called more than
> once.
> > > > 
> > > 
> > > http://webaudio.github.io/web-audio-api
> > > 
> > > I checked it. There is still mentioning about it in the table 2.9.2
Methods
> > > "when" .
> > > The specification represents start() can not be called after calling
stop().
> > > start() should be called before calling stop().
> > > It doesn't means stop() can called several time.
> 
> Oh, I think that is a mistake. The description for the stop method shows that
> stop can be called more than once. The actual discussion on the W3C is here: 
> https://github.com/WebAudio/web-audio-api/issues/15. I'll file an issue about
> the text.
> 

Thanks for sharing information. If I understand that closed discussion,
that seems to be allowing a multiple stop()s, not a multiple start().
As Chris Roger's original intent, AudioBufferSourceNode can be played only once.
JS developer can call multiple stop() whenever calling start or not to apply
last calling should be affected.
Their decision can allow calling stop() before calling start() as well because
it was too much strict.

I saw "https://github.com/WebAudio/web-audio-api/issues/297" you raised.
Do you think start() and stop() should can be called multiple times both ?
Could you give me your opinion? I hope my understanding about all english
context.


> > > So, JS developer should create new buffer after stop(). It can not be used
> > > anymore actually after calling stop once.
> > > In the specification, there is still nullable buffer.
> > > I understand what you are raising issue to specification. 
> > > However, I believe that setBuffer should work with new buffer and
rendering
> > > immediately if it was started.
> 
> The problem is that "rendering immediately" is not clear. There is some time
> between the JS call to set the buffer and when it actually starts rendering. 
> This could be on the order of many 10s of milliseconds or more if GC happens
> just after the JS call, but before it makes its way to the audio thread.
> 

I think there is my fault that description was not clear.
In the specificaiotn , there is still mentiong about nullable buffer.
I think that AudioBufferSourceNode should be able to set buffer anytime whatever
node is playing or not.

< case1 >
sourcenode.buffer = null;
sourcenode.start(0); // mute
...
sourcenode.buffer = meaningfulbuffer; // sound occure

< case2 >
sourcenode.buffer = meaningfulbuffer;
sourcenode.start(0); // sound occure
...
sourcenode.buffer = null; // mute
...
sourcenode.buffer = meaningfulbuffer; //sound occure

< case 3 >
sourcenode.start(0);
sourcenode.buffer = meaningfulbuffer; // sound occure

< case 4 >
sourcenode.buffer = meaningfulbuffer;
sourcenode.start(0); // sound occure

In my opinion, all cases should be work properly such as firefox.
If there is setBuffer() with null, it should be slient with mono channel output
in specification.
However, it is just my opinion in specification expected, we need to wait
everyone accepted.

> > > 
> > > > > 
> > > > > So, original source code is not allowed call several times about
start()
> > and
> > > > > stop() methods.
> > > > > 
> > > > > Actually there was FIXME about nullable buffer supporting. If
setBuffer
> is
> > > > > called during playing previous buffer, 
> > > > > it should be replaced and working with new buffer. The original source
> > code
> > > > > works as my comment.
> > > > > 
> > > > > This feature can be AudioBufferSourceNode muted without changing gain
or
> > > call
> > > > > stop().
> > > > > After stop(), JS developer has to create new AudioBufferSourceNode and
> set
> > > all
> > > > > values again.
> > > > > 
> > > > > I attached sample file in BUG=350768. Firefox browser works as
> > specification
> > > > > expected.
> > > > > 
> > > > > Please check again. I think it gives many thing to JS developer.
> > 
> > Sorry about no more quick response. Korea is almost 5 am. I need to go to
the
> > bed. :)
> > I'm really happy having this kind of discussion about web audio. Actually
> there
> > are no many engineers around me.
> > Thank you always. I'm exciting contributing of patch about web audio.
> 
> No worries. I don't expect answers from you after a normal workday. And it's
> always better to have discussions when a participant is not suffering from
lack
> of sleep!
> 
> I appreciate all of your CLs.  Makes me really think about how things are
> supposed to work and that's good.

[KhNo, 2014-03-26 12:51:46]

This patch is required "Decision from discussion of  w3c audio working group"

[KhNo, 2014-05-07 13:15:32]

This patch couldn't get consensus for audio working group.
After fixing .buffer behavior, patch will be re-raised by someone.

This patch just closed for referring by others.