RE: AudioBufferSourceNode.buffer how to work it.

@Karl
I should have explicitly explain. Sorry to making confused.
Step 3. is executed after executing Step 1 or Step 2.
I would like to change "Previous DOMexception causes error, no sound." ->
"Previous DOMexception which is from Step 1 causes error, no sound in step
3."

Another case executing step 2 then step3, there is nothing happens in step3
because an AudioSourceBufferNode is FINISHED_STATE by it's life cycle.


Br,
Khno.

-----Original Message-----
From: Karl Tomlinson [mailto:karlt+public-audio@karlt.net] 
Sent: Friday, March 21, 2014 11:21 AM
To: KeonHo Kim
Cc: 'Chris Wilson'; 'Raymond Toy'; public-audio@w3.org
Subject: Re: AudioBufferSourceNode.buffer how to work it.

KeonHo Kim writes:

> Well, I'm not sure my testing is related with that bug.
> I tested blink and webkit were the latest and built locally.
> The patch from the bug was applied both. I think it is not related this
bug.

Perhaps I don't understand.  Please see my question below.

> KeonHo Kim writes:
>
>> 1. When JS calls start(0) without setting a buffer.
>> Blink/Webkit -> Immediately SourceNode's playback state changed to 
>> FINISHED_STATE, no DOMexception.
>> Gecko -> Just slience, no DOMexception.
>>
>> 2. When JS calls start(0) with setting 'null' javacript object.
>> Blink/Webkit -> DOMexception. "Cannot set to null"
>> Gecko -> Just slience, no DOMexception.
>>
>> 3. After 1 or 2, Then set a buffer after calling start(0) 
>> Blink/Webkit
>> -> Previsouly DOMexception causes error, no sound.
>> Gecko -> Playing from beginning of buffer.

There is no DOMexception after only 1 (without 2), so where does the
DOMexception come from or what do you mean by "After 1 or 2"?

Received on Friday, 21 March 2014 04:37:45 UTC