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

Re: AudioWorker proposal

From: Chris Wilson <cwilso@google.com>
Date: Fri, 18 Jul 2014 09:57:24 -0700
Message-ID: <CAJK2wqUXhtctD1d4C34hc+prCwWjCBuFmMJV8M_6OJ2McvuzEA@mail.gmail.com>
To: Joseph Berkovitz <joe@noteflight.com>
Cc: Paul Adenot <paul@paul.cx>, "public-audio@w3.org" <public-audio@w3.org>
Yes, that's somewhat correct.  The only bit that isn't correct is that it
probably shouldn't really be an AudioProcessingEvent - because since the
goal is to be synchronous, it should be called directly, not posted or
fired.  Something like (totally off the top of my head):

[Constructor(DOMString scriptURL, optional unsigned long bufferSize)]
interface AudioWorker : Worker {
};
callback AudioProcessCallback = void (double playbackTime, AudioBuffer
buffer);interface AudioWorkerGlobalScope : DedicatedWorkerGlobalScope
{  attribute AudioProcessCallback audioprocess;  readonly attribute
float sampleRate;};
interface ScriptProcessorNode : AudioNode {  readonly attribute double
latency;  readonly attribute AudioWorker worker;};
partial interface AudioContext {  ScriptProcessorNode
createScriptProcessor(    DOMString scriptURL,    optional unsigned
long bufferSize = 0,    optional unsigned long numberOfInputChannels =
2,    optional unsigned long numberOfOutputChannels = 2);}



On Thu, Jul 17, 2014 at 11:28 AM, Joseph Berkovitz <joe@noteflight.com>
wrote:

> Hi Chris,
>
> I remember the issue (and contributed some comments to it at the time) but
> it’s difficult to determine the exact proposal that was discussed at last
> week’s meeting, since a number of variants are proposed in github issue 113
> with different folks suggesting this flavor or that flavor.
>
> From the fact that Olivier called this “synchronous”, I'm guessing that
> you were discussing an AudioWorker object that executes directly in the
> audio thread and doesn’t have to deal with message-passing. I infer that an
> AudioWorker obtains its input (and output?) audio buffer directly from an
> AudioProcessingEvent passed to the worker’s “onaudioprocess” function
> defined in its AudioWorkerGlobalScope. This was proposed in your comment of
> March 26, I think.
>
> Is that understanding correct? Were further changes to this approach
> discussed?
>
> …Joe
>
> On Jul 17, 2014, at 1:03 PM, Chris Wilson <cwilso@google.com> wrote:
>
> It's mostly written up in the issue (
> https://github.com/WebAudio/web-audio-api/issues/113), but I realized on
> the call that I hadn't yet written out an IDL for how the synchronous
> version would work.
>
>
> On Thu, Jul 17, 2014 at 9:53 AM, Paul Adenot <paul@paul.cx> wrote:
>
>>  On Thu, Jul 17, 2014, at 06:43 PM, Joseph Berkovitz wrote:
>>
>> Hi Olivier,
>>
>> On Jul 11, 2014, at 6:16 AM, Olivier Thereaux <olivier.thereaux@bbc.co.uk>
>> wrote:
>>
>>
>> * Progress of scriptprocessornodes in workers issue
>> We discussed a proposal for a synchronous model for the node. There will
>> also be a Call for Consensus soon on the possibility of breaking changes
>> for the main thread ScriptProcessorNode.
>>
>>
>>
>> Is there a writeup of the proposal that was discussed?
>>
>>
>> Not as far as I know. We kind of agreed on a super high level, but
>> nothing very solid yet.
>>
>> Paul.
>>
>
>
>
>
> .            .       .    .  . ...Joe
>
> *Joe Berkovitz*
> President
>
> *Noteflight LLC*
> Boston, Mass.
> phone: +1 978 314 6271
> www.noteflight.com
> "Your music, everywhere"
>
>
Received on Friday, 18 July 2014 16:57:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:14 UTC