- From: Philip Jägenstedt <philipj@opera.com>
- Date: Fri, 01 Jun 2012 14:50:50 +0200
- To: "Audio Working Group" <public-audio@w3.org>, "olivier Thereaux" <olivier.thereaux@bbc.co.uk>
On Fri, 25 May 2012 12:39:04 +0200, olivier Thereaux <olivier.thereaux@bbc.co.uk> wrote: > On 15 May 2012, at 16:09, Audio Working Group Issue Tracker wrote: > >> Audio-ISSUE-49 (AudioBufferDirectAccess): AudioBuffer direct access >> [Web Audio API] >> >> http://www.w3.org/2011/audio/track/issues/49 >> >> Raised by: Philip Jägenstedt >> On product: Web Audio API >> >> getChannelData is documented as "Gets direct access to the audio data >> stored in an AudioBuffer" but "direct access" is not defined. >> >> For example, if a reference to an AudioBuffer is kept and the data is >> modified after the audioprocess event handler has finished running, >> what will happen? >> >> One approach would be similar to what happens with postMessage and >> typed arrays, at least in Opera. There, once the ownership of an array >> is transferred, it becomes a dummy array of length zero that cannot be >> modified. This does not require copying the memory to achieve >> "concurrency safety", it is merely a flag on the ECMAScript host object. > > This issue is now pending review, per > https://dvcs.w3.org/hg/audio/rev/5f1f174d7603 The suggested change effectively requires the audio data to be copied when the audioprocess callback returns, which isn't necessary to solve the problem. We suggest defining it in terms of ownership transfer,[1] like when a typed array is used with postMessage. In other words, the Float32Array should be neutered, after which reading the length property returns 0.[2] [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#transferable-objects [2] http://www.khronos.org/registry/typedarray/specs/latest/#7 -- Philip Jägenstedt Core Developer Opera Software
Received on Friday, 1 June 2012 12:51:18 UTC