Re: Help needed with a sync-problem

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! :)



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
>