W3C home > Mailing lists > Public > public-audio@w3.org > January to March 2014

RE: AudioBufferSourceNode.buffer how to work it.

From: KeonHo Kim <keonho07.kim@samsung.com>
Date: Fri, 21 Mar 2014 11:16:17 +0900
To: 'Karl Tomlinson' <karlt+public-audio@karlt.net>
Cc: 'Chris Wilson' <cwilso@google.com>, 'Raymond Toy' <rtoy@google.com>, public-audio@w3.org
Message-id: <011d01cf44ab$8a9e4bc0$9fdae340$@samsung.com>
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.
The bugs has been fixed,
https://code.google.com/p/chromium/issues/detail?id=334237


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

KeonHo Kim writes:

> This is current implementation in engine side by internal my test sample.
>
> 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.

Sounds like the Blink version that you tested still has this bug:
https://code.google.com/p/chromium/issues/detail?id=334237

Which Webkit version did you test?
Received on Friday, 21 March 2014 02:27:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:13 UTC