Re: TAG feedback on Web Audio

Chris,


On Mon, Aug 5, 2013 at 3:46 AM, Chris Wilson <cwilso@google.com> wrote:

> (Sorry, on vacation, and beach > Web Audio discussions. :)
>
> Alex, as we discussed a few weeks ago - glitch-free,
> reasonably-low-latency audio is something that I just don't believe JS - *as
> it is today - *can do.
>
>
...as I read it ("introduces effects to JS that can't be described *in
terms of JS*"), Alex is not referring to the actual audio generation, but
rather the way data is shared between threads and how that affects the
interfaces.

So, not only would it be hard to implement the audio engine in JS from a
performance perspective, it would even be *impossible* to implement the
interfaces solely because of the shared data model (that JS doesn't have).
And as others have pointed out, it would be equally impossible to implement
it in other memory safe languages too, such as Rust.

One of the more practical side effects of this that just occurred to me
(that I think should concern the Audio WG) is that once we release version
2 of the spec later on, it's likely that it wouldn't be possible to create
a polyfill for it simply because there's no way to describe & implement the
new interfaces in JS alone (you need the engine side "magic" that Alex
mentioned).

/Marcus



>
> On Thu, Aug 1, 2013 at 5:42 PM, Alex Russell <slightlyoff@google.com>wrote:
>
>> Let me be clearer, then: the issue is that it introduces effects to JS
>> that can't be described *in terms of JS*. It violates the
>> run-to-completion model of the language without appealing to the turn-based
>> concurrency model we use everywhere else in the platform.
>>
>>
>> On Wed, Jul 31, 2013 at 10:43 AM, Chris Wilson <cwilso@google.com> wrote:
>>
>>> In addition, I'd ask that you be more explicit than calling this problem
>>> "data races", because there's clearly some explicit effect you're trying to
>>> prevent.  Any asynchronously-programmable or event-driven system can enable
>>> developers to introduce race conditions.
>>>
>>>
>>> On Mon, Jul 29, 2013 at 10:09 PM, Noah Mendelsohn <nrm@arcanedomain.com>wrote:
>>>
>>>>
>>>>
>>>> On 7/29/2013 7:05 PM, Anne van Kesteren wrote:
>>>>
>>>>> On Sat, Jul 27, 2013 at 9:22 AM, Noah Mendelsohn<nrm@arcanedomain.**
>>>>> com <nrm@arcanedomain.com>>  wrote:
>>>>>
>>>>>> >Again, I have no informed opinions on the specific merits, just
>>>>>> suggesting a
>>>>>> >useful role the TAG might play to clarify for the many members of the
>>>>>> >community who are less expert on this than you are. Thank you.
>>>>>>
>>>>>
>>>>  I'm not sure we call out data races anywhere, it's something we just
>>>>> don't do.
>>>>>
>>>>
>>>> Well, my recollection may be faulty, but I think that one of the
>>>> reasons the TAG took the trouble to formalize things like the architecture
>>>> document was the belief that it's easier to ask skeptics to stick to rules
>>>> that have been written down, and especially those that have garnered formal
>>>> consensus through something like the Recommendation track.
>>>>
>>>> Whether it's worth taking a guideline on data races all the way to Rec
>>>> I'm not sure, but it seems that it would be worth setting it down formally,
>>>> perhaps in a TAG Finding/blog post/Recommendation or whatever will get the
>>>> right level of discussion, consensus building, and eventually attention.
>>>>
>>>> Certainly, of the many things that have come up recently relating to
>>>> APIs, this one seems deeply architectural and very much within the TAG's
>>>> remit.
>>>>
>>>> Noah
>>>>
>>>>
>>>
>>
>