Re: Issues with ROC's proposal

1) & 2) to me, the value of ROC's proposal is that in most cases, the
getChannelData() method can continue to be used precisely as it is today.

3) I thought we'd agreed that the AudioProcessingEvent  was a separate
topic at some point.  Either way - I'm not opposed to discussing making
AudioProcessingEvent use arrays of Float32Arrays instead of AudioBuffers.

4) I still consider this a feature, not a bug.  :)


On Mon, Sep 2, 2013 at 2:56 AM, Marcus Geelnard <mage@opera.com> wrote:

>  Hi all!
>
> Since we have a Cfc coming up, I'd like to get some feedback on a few
> points about ROC's proposal for AudioBuffers [1], since I'm a bit short on
> ideas myself.
>
> Generally speaking I'm in the "can live with" camp. I.e. I'm not happy
> with the syntax/semantics, but I understand the position of supporting
> existing content, and it's hard to do anything much different from ROC's
> proposal without breaking existing content (if that indeed is the main
> goal).
>
>
> *The main things that bother me about the proposal are*:
>
>
> 1) The naming/functionality of getChannelData().
>
> If we disregard the case of the AudioProcessingEvent (see below), the main
> purpose (at least a very important function) of getChannelData() seems to
> be to *set* the channel data.
>
> We now have the copyChannelDataTo() method for getting a persistent
> version of the channel data, while the getChannelData() is used for getting
> a volatile (sometimes persistent!) version of the channel data that may
> later be transfered back to the AudioBuffer.
>
> IMO this is confusing (i.e. "get" ~= set/modify, "copy" == get), to say
> the least.
>
>
> 2) The getChannelData() method can return a persistent copy.
>
> If you call getChannelData() on an AudioBuffer that is in use, you will
> get a persistent copy of the AudioBuffer data (i.e. modifying the data does
> nothing to the AudioBuffer, and the array will never be neutered), which
> kind of goes against the purpose of getChannelData(). Again, I find this
> quite confusing.
>
> I think that a better solution would be to throw in that case (or possibly
> return an empty array).
>
>
> 3) The AudioProcessingEvent still uses AudioBuffers.
>
> I realize that not all agree that this is a problem, but this complicates
> the semantics of the AudioBuffer (among other things). For instance, in an
> AudioProcessingEvent getChannelData() is used both for getting the input
> channel data and for setting the output channel data.
>
> IMO the better solution would be to pass pure Float32Arrays in the event
> handler instead (using neutering and ownership transfer as necessary).
>
>
> 4) Data transfer from JS to an AudioBuffer is implicit.
>
> The data transfer from JS to an AudioBuffer is implicit by design, rather
> than explicit. This is confusing, and could lead to hard-to-find bugs.
>
> In general it's also sub-optimal from a performance perspective, since
> it's easier to design a performance critical application if you can limit
> possible performance hits to explicit points in your code (e.g. let them
> happen during pre-processing/loading stages rather than during playback
> stages). Now, since the proposal relies heavily on neutering this might not
> be much of an issue, but I still think that it's a good idea to at least
> *consider* an implementation that does "acquire the contents" using a copy
> operation.
>
>
> *Possible solutions*?
>
> It's hard to both be backwards compatible and offer solutions to the above
> issues without introducing new interfaces and keeping the old interfaces
> only as deprecated. We've already been over that, and it seems to be a bad
> idea to have deprecated interfaces in the v1 spec.
>
> However, I can think of at least two solutions for the future:
>
> A) Once we introduce worker-based processing nodes we could consider using
> a slightly different design for those, hopefully one that does not include
> AudioBuffers at all.
>
> B) We could also consider deprecating getChannelData() in favor of a more
> explicit interface in a future version of the API.
>
>
> /Marcus
>
>
>
> [1] https://wiki.mozilla.org/User:Roc/AudioBufferProposal
>
> --
> Marcus Geelnard
> Technical Lead, Mobile Infrastructure
> Opera Software
>
>
>
>