Re: Help needed with a sync-problem

On Fri, Aug 3, 2012 at 10:38 PM, Adam Goode <agoode@google.com> wrote:

> There is a tension in the development in these kinds of systems, where you
> have a high-speed-but-static part (example: non-js nodes) and
> slower-but-dynamic part (example: js nodes). (Another example that comes to
> mind is game engines written in C with lua for scripting.)
>
> One common mechanism for development is make the slow part completely
> general and then speed up the slowest parts with fast custom code. In web
> audio, this would mean removing everything but jsnodes, and allowing
> everything to be implemented there. Once bottlenecks are found, the
> underlying system can provide high speed nodes.
>
> Another way to do it is to start with some informed notions of what must
> be provided by the runtime system, but still allow some kinds of custom
> processing (perhaps with some limitations). This is the current state of
> web audio.
>
> Both of these approaches are valid and have different tradeoffs. A lot of
> discussion recently has been related to this kind of tension.
>
>
> I think a good way forward at this point would be for someone to write
> "webaudio.js", which attempts to reimplement all of the existing webaudio
> nodes only in terms of jsnodes. This way, we can: more easily enumerate the
> exact limitations of the current javascript node mechanism, help to inform
> the new DSP draft, and have another implementation of the standard nodes.
> Any issues found can be filed as bugs against the underlying implementation.
>
> I suspect that this will be mostly doable and interesting, so someone
> should do it! :)
>

Very good analysis, Adam!

We (Official.fm Labs) have been planning to do something like that
(webaudio.js) for a while now. I think Marcus also volunteered to do this?
Anyway we'd be glad to give a hand.

The main blocking issue for that is this:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17388

Cheers,
Jussi


>
>
> Adam
>
>
>
> On Fri, Aug 3, 2012 at 2:53 PM, Jussi Kalliokoski <
> jussi.kalliokoski@gmail.com> wrote:
>
>> On Fri, Aug 3, 2012 at 9:50 PM, Chris Wilson <cwilso@google.com> wrote:
>>
>>> On Fri, Aug 3, 2012 at 11:20 AM, Jussi Kalliokoski <
>>> jussi.kalliokoski@gmail.com> wrote:
>>>
>>>> On Fri, Aug 3, 2012 at 9:14 PM, Chris Wilson <cwilso@google.com> wrote:
>>>>
>>>>> On Fri, Aug 3, 2012 at 10:37 AM, Jussi Kalliokoski <
>>>>> jussi.kalliokoski@gmail.com> wrote:
>>>>>
>>>>>> On Fri, Aug 3, 2012 at 8:21 PM, Chris Wilson <cwilso@google.com>wrote:
>>>>>>
>>>>>>> How would you empower the JS node/DSP API to fix this?
>>>>>>
>>>>>>
>>>>>> By making it possible to do fast processing without using the native
>>>>>> nodes.
>>>>>>
>>>>>
>>>>> Well I get that - _HOW_ was my question, not WHAT.
>>>>>
>>>>
>>>> By improving the DSP API and getting it out there soon. On the Web
>>>> Audio API side, for example these: [1] [2] [3].
>>>>
>>>> [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17415
>>>> [2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17388
>>>> [3] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17533
>>>>
>>>
>>> None of those bugs are a way to fix the problem Peter pointed out - that
>>> the buffers in JSNode are going to cause latency.  (I do consider all three
>>> of those to be valid issues - in fact, I think the first time I met Chris
>>> FTF at TPAC 2011 I asked about adding worker thread based JS nodes.
>>>  Although I would point out thread priority is going to be an issue.)
>>>
>>
>> Quite correct, instead, they are bugs that make moving to completely
>> custom processing less inviting. My proposed solution was after all moving
>> to completely custom processing.
>>
>> Cheers,
>> Jussi
>>
>
>