W3C home > Mailing lists > Public > public-audio@w3.org > October to December 2012

[Bug 17388] (audioparam): AudioParam constructor

From: <bugzilla@jessica.w3.org>
Date: Mon, 03 Dec 2012 23:36:10 +0000
To: public-audio@w3.org
Message-ID: <bug-17388-5429-RGZYAAlbzw@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17388

--- Comment #9 from Ray Bellis <ray@bellis.me.uk> ---
(In reply to comment #8)

> I like the idea of having anonymous AudioParams, it does indeed simplify
> things.

Great :)

> I'm not sure what you're after with this part. Your suggestion has no way of
> differentiating between k-rate and a-rate parameter inputs, which has
> implications on performance. I think that we should just change the previous
> proposal a bit to accommodate:
> 
> partial interface AudioProcessingEvent {
>     void getParamValues(uint index, Float32Array values);
>     float getParamValue(uint index);
> }

AIUI, whether an AudioParam is a-rate or k-rate depends on the specification of
each type of AudioNode.  It's actually not clear to me that k-rate AudioParams
make sense in the context of a ScriptProcessorNode.

I'm not intimately familiar with the internals of any of the WebAudio
implementations, but it sounds like your second function prototype wouldn't fit
with the requirement that k-rate samples are taken on a 128 sample block
boundary, given that a ScriptProcessorNode could easily be processing a block
longer than that.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Monday, 3 December 2012 23:36:15 UTC

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