W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2012

Re: Thoughts and questions on the API from a modular synth point of view

From: Chris Wilson <cwilso@google.com>
Date: Fri, 3 Aug 2012 08:07:38 -0700
Message-ID: <CAJK2wqWtr0ophssOquWc9Y9AF_+xzQxSG6sevkrA8J7nR36Uig@mail.gmail.com>
To: robert@ocallahan.org
Cc: Peter van der Noord <peterdunord@gmail.com>, Chris Rogers <crogers@google.com>, "public-audio@w3.org" <public-audio@w3.org>
On Thu, Aug 2, 2012 at 5:23 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Fri, Aug 3, 2012 at 4:41 AM, Chris Wilson <cwilso@google.com> wrote:
>
>> Chris and I have talked through many different "pausing" behaviors - and
>> I'm quite sure he's thought about it even more.  The problem is there isn't
>> one logical solution - for example, your "I want to stop audiocontext from
>> asking for more buffers [temporarily]": how does that deal with an upstream
>> source from a microphone input (via getUserMedia)?  Is it really "pausing"
>> - i.e. recording like a DVR?  How much time can it buffer?  You'd probably
>> also want a fast-forward API then... and this starts looking less tenable.
>>  It would also be a confusing challenge when audiocontext.currentTime
>> doesn't always proceed forward at a steady rate - or (more likely) when
>> branches of the audio graph want to get out of sync (because you really
>> want to "pause" branches, not always the whole graph - that's what the
>> Fieldrunners guys wanted<http://www.html5rocks.com/en/tutorials/webaudio/fieldrunners/>,
>> so they could pause the game effects but keep the menu effects going).
>>
>
> These problems can all be solved:
> 1) Support currentTime on each AudioNode.
>

Gah.  I can envision what you'd need to code around this solution, and yes,
exposing the currentTime on every AudioNode would be part of it; my point
was that it's not just adding "pause", it completely changes the concept of
one monotonically proceeding audio clock.


> 2) When a getUserMedia stream feeds into a paused node, drop data. For
> authors who actually want DVR-like buffering we probably should invent an
> entirely new kind of MediaStream that specifically does that.
>

How does it drop data, exactly?  Because that's probably going to sound
like a glitch.


> 3) When a media element stream feeds into a paused node, you have the
> option of either pausing the media element or dropping data. We could
> expose API to give the author control (c.f. the blockInput flag from MSP)
> 4) For each connection within in audio graph, you could provide the
> equivalent of blockInput/blockOutput from MSP. Sensible defaults might be
> to say that blockInput is true and blockOutput is false, i.e., a paused
> stream feeding into a non-paused stream is treated as silence, but any
> stream feeding into a paused stream is forced to pause.
>

My intent was not to say "this is impossible" - just "this makes a lot of
things complex, just to make a single scenario very easy - and it's not
impossible now."
Received on Friday, 3 August 2012 15:08:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 3 August 2012 15:08:11 GMT