W3C home > Mailing lists > Public > public-audio@w3.org > April to June 2012

Re: Audio-ISSUE-49 (AudioBufferDirectAccess): AudioBuffer direct access [Web Audio API]

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>
Message-ID: <op.we75y0p4sr6mfa@kirk>
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]

[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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:49:59 UTC