W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2013

Re: [web-audio-api] (audioparam): AudioParam constructor (#134)

From: Olivier Thereaux <notifications@github.com>
Date: Wed, 11 Sep 2013 07:29:52 -0700
To: WebAudio/web-audio-api <web-audio-api@noreply.github.com>
Message-ID: <WebAudio/web-audio-api/issues/134/24244466@github.com>
> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17388#8) by Ray Bellis on W3C Bugzilla. Mon, 03 Dec 2012 23:36:10 GMT

(In reply to [comment #8](#issuecomment-24244457))

> 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.

---
Reply to this email directly or view it on GitHub:
https://github.com/WebAudio/web-audio-api/issues/134#issuecomment-24244466
Received on Wednesday, 11 September 2013 14:35:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:24 UTC