- From: Philip Jägenstedt <philipj@opera.com>
- Date: Wed, 16 May 2012 17:19:29 +0200
- To: public-audio@w3.org, "Robert O'Callahan" <robert@ocallahan.org>
On Thu, 10 May 2012 03:19:23 +0200, Robert O'Callahan
<robert@ocallahan.org> wrote:
> Imprecision in the spec has been discussed a bit before but the issues
> haven't been resolved so I want to itemize some details that need to be
> clarified. This is only based on a quick skim of the spec, there are
> probably a lot more like this.
There is a lot more, indeed.
> It needs to be specified (or derivable) what happens when someone
> creates a
> cycle in the graph.
We agree: https://www.w3.org/2011/audio/track/issues/24
If circular routing is not to be allowed, I quite like the solution in
MSP, to consider that graph blocked. To require throwing an error
synchronously would require checking for loops on every operation :(
> In AudioParam, a lot of the processing model is unclear. I assume that
> nominally an AudioParam is a function from time to floats. So, for
> example,what does setValueAtTime actually do? Does it set the value for
> all
> times >= 'time'? Does setting the 'value' attribute make the function
> constant over all times? And what does it mean to be "relative to the
> AudioContext currentTime"? Does that mean passing 0 changes the value at
> the current time, or that 'time' and 'context.currentTime' are simply on
> the same timeline? If the former, clarify by saying that 0 corresponds to
> the context's currentTime.
>
> The actual values computed by the AudioParam curves must be specified
> mathematically. The current text is too vague to be implemented.
We agree:
https://www.w3.org/2011/audio/track/issues/34
https://www.w3.org/2011/audio/track/issues/35
https://www.w3.org/2011/audio/track/issues/36
https://www.w3.org/2011/audio/track/issues/37
https://www.w3.org/2011/audio/track/issues/38
https://www.w3.org/2011/audio/track/issues/39
https://www.w3.org/2011/audio/track/issues/40
https://www.w3.org/2011/audio/track/issues/41
https://www.w3.org/2011/audio/track/issues/42
> Do AudioBuffers created on one AudioContext work with other
> AudioContexts?
> This needs to be specified.
I agree, can you enter this into
<https://www.w3.org/2011/audio/track/issues/new>?
> AudioBuffer.getChannelData needs to specify that it returns the same
> array
> every time and that modifying the array alters the buffer data. (Unless
> it
> does something else, in which case that should be specified instead.)
We agree: https://www.w3.org/2011/audio/track/issues/48
Since the spec talks about direct access, it seemed to us that a getter
serves no purpose and that the following interface would suffice:
interface AudioBuffer {
readonly attribute float sampleRate;
Float32Array[] data;
}
--
Philip Jägenstedt
Core Developer
Opera Software
Received on Wednesday, 16 May 2012 15:19:56 UTC