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
Received on Friday, 3 August 2012 18:53:43 UTC