Re: Requirements for Web audio APIs

On Sun, May 22, 2011 at 9:10 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Mon, May 23, 2011 at 2:58 PM, Chris Rogers <crogers@google.com> wrote:
>
>> I see it as more of an advantage than a problem.  In object-oriented
>> design, it's often a good idea to separate out concepts into separate types
>> of objects with "has-a" relationships instead of lumping together distinct
>> and separate concepts into monolithic object classes.  As an example of two
>> quite different types of objects I would look at HTMLMediaElement, a type
>> which is very much concerned with network state and buffering as evident in
>> its API.   And the AudioNode,  which deals with concepts very particular to
>> audio, connections with processing nodes in a graph, etc.   So, I see it as
>> an advantage to keep them separate.
>
>
> The apparent redundancy is with AudioNode and Stream, not HTMLMediaElement.
>

For Stream, I assume you're talking about Ian's media capture and
peer-to-peer streaming proposal:
http://www.whatwg.org/specs/web-apps/current-work/complete/video-conferencing-and-peer-to-peer-communication.html

This is designed for peer-to-peer communication.  It's clearly not designed
for and does not solve the types of use cases and audio processing tasks
which the Web Audio API is designed to solve.  They're different APIs each
with their own much different focus and orientation, so I think it's a
considerable stretch to call them redundant.  That said, there's an
opportunity for the two APIs to have a relationship, similar to what I've
already proposed with respect to HTMLMediaElement.  I think the most
interesting question will be how the Web Audio API is able to make use of
the getUserMedia() method to gain access to audio input. getUserMedia() is a
proposed API for getting the user's permission to use the microphone (audio
input) and/or camera.  We should be careful that this API is designed
generally and is not limited to simply the peer-to-peer communications use
case.

Chris