RE: AudioBufferSourceNode.buffer how to work it.

2014-03-12 2:31 GMT+09:00 Raymond Toy < <mailto:rtoy@google.com> rtoy@google.com>:



 

 

On Tue, Mar 11, 2014 at 2:03 AM, KeonHo Kim < <mailto:keonho07.kim@samsung.com> keonho07.kim@samsung.com> wrote:

Dear All.

 

If there is setting a buffer of AudioBufferSourceNode, how it should work?

I think that AudioBufferSourceNode.buffer should be able to set buffer anytime whatever the node is playing or not.

I believe if all cases are able to JS developer, it is fantastic.

 

I think that in all of the cases below, you don't have sample accurate timing. The sound for meaningfulbuffer will start at some uncontrolled time after setting the buffer.  I think in all cases you can get the effect you want by just creating a new AudioBufferSourceNode with the appropriate buffer and calling start and stop appropriately.

 

Chris Rogers certainly intended that AudioBufferSourceNodes to be cheap to create and use. 

 

Khno> I'm getting clear what he intended from discussion with you. I agree with you.

There is no "when" which can control accurate timing.

Don't we need to mention "setBuffer() must be called before calling start()" such like this?.

I think that will be helpful for developer.

 

 

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

 

This case is, I think, currently supported, but I find it's behavior odd because the sound will start at some uncontrolled time.

 

Khno> Actually, chrome returns domexception "ailed to set the 'buffer' property on 'AudioBufferSourceNode': buffer cannot be null" on sourcenode.buffer = null; 

Firefox is not.

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

 

I think this is better done by calling sourcenode.stop() instead of setting the buffer to null.  Then create a new new node with meaningfulbuffer.

 

Khno> Yes, it is better approach to keep idea that Chris Rogers intent. 

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

 

I think this is the same as case 1 

 

Khno> Firefox and Chrome work fine both.

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

 

This is the normal case. 

 

Khno> Firefox and Chrome work fine both.

< case 5 >
sourcenode.buffer = meaningfulbuffer1;
sourcenode.start(0); // sound buffer1

…

sourcenode.buffer = meaningfulbuffer2; // sound buffer2

 

I don't know how that is supposed to work, especially since start() is only allowed to be called once for each AudioBufferSourceNode.  Even if you allowed more than one call, I still don't know how this is supposed to behave.

 

 

Khno> Firefox and chrome are different.

 

In FF

If there is "sourcenode.buffer = meaningfulbuffer1" then start(0), play meaningfulbuffer1 from begin of buffer.

Then, if there is "sourcenode.buffer = meaningfulbuffer2", sound changed to meaningfulbuffer2 from begin of buffer.

Then, if there is "sourcenode.buffer = meaningfulbuffer1" again, play meaningfulbuffer1 from middle of buffer when "sourcenode.buffer = meaningfulbuffer2" was called.

 

In Chrome

If there is "sourcenode.buffer = meaningfulbuffer1" then start(0), play meaningfulbuffer1 from begin of buffer.

Then, if there is "sourcenode.buffer = meaningfulbuffer2", sound changed to meaningfulbuffer2 from begin of buffer.

Then, if there is "sourcenode.buffer = meaningfulbuffer1" again, play meaningfulbuffer1 from begin of buffer.

 

If a JS developer can not do setting buffer multiple times or not allow setting buffer after calling start() once, FF and Chrome have wrong behavior both.

How do you think this case ? Need to notify "Buffer can not be set more than once" ?

 

 

--

Ray

 

 

 

In spec, nullable buffer is existed which has mono channel silence can help making source muted to AudioBufferSourceNode without stop().

If setting buffer or calling start() is allowed more than once, AudioBufferSourceNode can be reused.

 

Is there any confirmed change about calling start() multiple times?

 

 

However, it also has some issue.

“The spec doesn't say, but the buffer attribute of an AudioBufferSourceNode should probably be only settable once.

If you've started the source node and change the buffer while the previous buffer is playing, you have no control over when the new source starts.”

 <https://github.com/WebAudio/web-audio-api/issues/288> https://github.com/WebAudio/web-audio-api/issues/288

 

Please feel free to give your opinion and correct way for Web Audio API.

 

Br,

Khno

 

 

 

 

From: Raymond Toy [mailto:rtoy@google.com] 
Sent: Wednesday, March 12, 2014 2:32 AM
To: KeonHo Kim
Cc: public-audio@w3.org
Subject: Re: AudioBufferSourceNode.buffer how to work it.

 

 

 

On Tue, Mar 11, 2014 at 2:03 AM, KeonHo Kim <keonho07.kim@samsung.com> wrote:

Dear All.

 

If there is setting a buffer of AudioBufferSourceNode, how it should work?

I think that AudioBufferSourceNode.buffer should be able to set buffer anytime whatever the node is playing or not.

I believe if all cases are able to JS developer, it is fantastic.

 

I think that in all of the cases below, you don't have sample accurate timing. The sound for meaningfulbuffer will start at some uncontrolled time after setting the buffer.  I think in all cases you can get the effect you want by just creating a new AudioBufferSourceNode with the appropriate buffer and calling start and stop appropriately.

 

Chris Rogers certainly intended that AudioBufferSourceNodes to be cheap to create and use. 

 

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

 

This case is, I think, currently supported, but I find it's behavior odd because the sound will start at some uncontrolled time. 

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

 

I think this is better done by calling sourcenode.stop() instead of setting the buffer to null.  Then create a new new node with meaningfulbuffer.

 

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

 

I think this is the same as case 1 

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

 

This is the normal case. 

< case 5 >
sourcenode.buffer = meaningfulbuffer1;
sourcenode.start(0); // sound buffer1

…

sourcenode.buffer = meaningfulbuffer2;

sourcenode.start(0); // sound buffer2

 

I don't know how that is supposed to work, especially since start() is only allowed to be called once for each AudioBufferSourceNode.  Even if you allowed more than one call, I still don't know how this is supposed to behave.

 

 

--

Ray

 

 

 

In spec, nullable buffer is existed which has mono channel silence can help making source muted to AudioBufferSourceNode without stop().

If setting buffer or calling start() is allowed more than once, AudioBufferSourceNode can be reused.

 

Is there any confirmed change about calling start() multiple times?

 

 

However, it also has some issue.

“The spec doesn't say, but the buffer attribute of an AudioBufferSourceNode should probably be only settable once.

If you've started the source node and change the buffer while the previous buffer is playing, you have no control over when the new source starts.”

https://github.com/WebAudio/web-audio-api/issues/288

 

Please feel free to give your opinion and correct way for Web Audio API.

 

Br,

Khno