W3C home > Mailing lists > Public > public-audio@w3.org > January to March 2012

Re: Newbie questions about web audio working group specs

From: Robert O'Callahan <robert@ocallahan.org>
Date: Wed, 1 Feb 2012 01:33:16 +1300
Message-ID: <CAOp6jLZwX-TczQ9N9=TYPNS8wCyVBhT18-+pCDQ9josDNzsw2Q@mail.gmail.com>
To: Samuel Goldszmidt <samuel.goldszmidt@ircam.fr>
Cc: public-audio@w3.org
Welcome!

On Tue, Jan 31, 2012 at 7:04 AM, Samuel Goldszmidt <
samuel.goldszmidt@ircam.fr> wrote:

>  First, you talk about *continuous real-time* media. At Ircam, we work on
> these questions, and, may be the *real time* word, is to restrictive, or
> may be we don't talk about the same thing. Sometimes, audio
> processing/treatments can't be done in real time:
>

I just meant that there's a time-varying signal that (in the steady state)
we want to process at the same rate as real time; e.g. we want to process
one second of data every second. And we want to be able to keep doing that
reliably (no dropouts), and with low latency (when possible). But I was
just using the phrase "continuous real-time" descriptively; I didn't intend
to refer to any formal definition of the term.

My demos include an example where the effect requires a very long delay ---
although not indefinitely long, as in your example.
http://people.mozilla.org/~roc/stream-demos/video-with-extra-track-and-effect.html
(get a browser build from here:
http://robert.ocallahan.org/2012/01/mediastreams-processing-demos.html)

(One last question: for mediastream extensions, as for effects that would
> be in level 2 specification, wouldn't it be better to have an overall
> createProcessor method for both workers and non-workers processor ?)
>

I suppose we could rename createWorkerProcessor to createProcessor and use
overloading to resolve them. It probably doesn't matter much.

Finally, correct me if I'm wrong, the main difference I have seen between
> Web Audio API by Chris Rogers and MediaStream Procession API by Robert
> O'Callahan is that in the second, all media processing are more linked with
> DOM objects (media elements in this case) than in the first one (although
> the graph of the first API seems to me much more easy to understand at
> first time), which make sense in my point of view.
>

There are a number of other differences. I mentioned some of them here:
http://robert.ocallahan.org/2012/01/mediastreams-processing-demos.html

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not
in us. If we confess our sins, he is faithful and just and will forgive us
our sins and purify us from all unrighteousness. If we claim we have not
sinned, we make him out to be a liar and his word is not in us." [1 John
1:8-10]
Received on Tuesday, 31 January 2012 12:33:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 31 January 2012 12:33:46 GMT