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

Re: [minutes] Audio WG teleconference, 2014-09-18

From: Joe Berkovitz <joe@noteflight.com>
Date: Sat, 20 Sep 2014 09:34:12 -0400
Message-Id: <CD75347E-3CC7-43F8-9907-3063B2E5C743@noteflight.com>
Cc: Olivier Thereaux <olivier.thereaux@bbc.co.uk>, Audio WG <public-audio@w3.org>
To: Chris Wilson <cwilso@google.com>

> On Sep 19, 2014, at 5:26 PM, Chris Wilson <cwilso@google.com> wrote:
> On Fri, Sep 19, 2014 at 12:21 PM, Joseph Berkovitz <joe@noteflight.com> wrote:
>>> Actually, not true - in this case, you can easily still expose non-AudioParam attributes and methods on the AudioWorkerNode; you just then need to hook them up (via getters and setters on the attribute) to a postMessage implementation.  Yes, postMessage is in the path; that doesn't mean the user has to see it as "postMessage( {"type":"sawtooth"} );”
>> Thanks — I see that one would have to have some locally cached value to deliver a synchronous result, but no big deal.
> On which side?  There is no such thing as synchronous across the thread boundary (there isn't today, either) - but on the main thread side your getter and setter would keep the value, as it would on the other side, so it would act as a synchronous property in each thread. 

Yes, I meant locally cached in the audio node, on the main thread side of the boundary, just as you said; I considered the value in the worker to be the true, non-cached working value. One could look at that either way, I think. 

By synchronous result, I meant synchronous in the ordinary sense: the caller of some function on the node gets a meaningful return value, immediately, with no thread handoff or callback needed. (A postMessage may have occurred invisibly under the hood but that's not part of delivering the return value.)

About the other topic of defining node behavior more carefully: I need more time than I have right now to respond in more detail and will do so in a subsequent email. 

Received on Saturday, 20 September 2014 13:34:42 UTC

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