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

Re: Web Audio API / WebRTC Integration

From: Chris Rogers <crogers@google.com>
Date: Mon, 17 Oct 2011 12:27:04 -0700
Message-ID: <CA+EzO0=ZBgbtwxsqCD5SYNFmfhfQbN8HhxCc0sGen+peMAEQDA@mail.gmail.com>
To: robert@ocallahan.org
Cc: Alistair MacDonald <al@signedon.com>, public-audio@w3.org
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

Received on Monday, 17 October 2011 19:27:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:49:57 UTC