Re: Web Audio API / WebRTC Integration

On Mon, Oct 17, 2011 at 5:05 AM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Sun, Oct 16, 2011 at 5:52 PM, Alistair MacDonald <al@signedon.com>wrote:
>
>> Group: if you are attending the AudioWG Telecon this Tuesday, please read
>> through the links Chris posted, this is a great starting point for
>> Agenda-Item-3 (Integration with other audio APIs).
>>
>> [1]
>> http://hg.mozilla.org/users/rocallahan_mozilla..com/specs/raw-file/tip/StreamProcessing/StreamProcessing.html#examples<http://hg.mozilla.org/users/rocallahan_mozilla.com/specs/raw-file/tip/StreamProcessing/StreamProcessing.html#examples>
>> [2]
>> https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/webrtc-integration.html
>>
>> As I mentioned in my other email, in many of these examples having to
> bridge Web Audio and MediaStream APIs adds unnecessary complexity. From the
> author's point of view there are unnecessary API calls, and two
> variables/objects representing the same thing.
>

In looking at the code examples, it's not clear that this is actually
tangibly more complex.  In fact, I would argue the opposite.  Many of
your processing examples invoke a worker with non-trivial JavaScript file
(such as "spatializer.js") where you're hiding a considerable amount of code
(hundreds to thousands of lines of JS) to implement the processing.  I would
argue that this introduces unnecessary complexity, particularly for the very
common use cases of games, interactive applications, and
spatializing/filtering a peer's audio source in WebRTC applications.

In object-oriented design, it is often better to avoid a monolithic
inheritance design where too many responsibilities are put into the API of a
single object type.  This can result in a "fragile base class" problem and
makes it difficult for the user of the API, and makes it much more difficult
to extend/modify the API in the future.  I believe this is a problem with
your approach.  Instead, a more modular design allows for APIs which can be
designed very precisely to address the special needs required by the use
cases.

Chris