[music-dsp] music dsp in javascript/firefox

Sylvain Le Beux artheist at gmail.com
Mon Sep 13 18:09:47 EDT 2010


I might be wrong but i am pretty sure that interpreted language like SuperCollider does have a RT garbage collector ...not js though but still.

My 2 cts


Le 13 sept. 2010 à 23:48, Stephen Sinclair <radarsat1 at gmail.com> a écrit :

> On Fri, Sep 10, 2010 at 12:12 AM, Ross Bencina
> <rossb-lists at audiomulch.com> wrote:
>>> Maybe I'm oldschool but I'm surprised javascript can handle the
>>> throughput. Anyone know much more about this? Is it really practical for
>>> applications? (Maybe some JIT compiling or something going on?)
>> Computers are pretty fast these days. There's a number of audio processing
>> apps written in Flash (more or less JS I guess). I'm thinking of things like
>> http://www.audiotool.com/ and splicemusic (now disappeared apparently ).
>> Most JS engiens use JIT compiling now as far as I know (Apple's and Google's
>> anyway). The main problem (imho) is that the current JS engines don't seem
>> to offer incremental real-time garbage collection.  I havn't found any
>> online benchmarks but apparently Google V8 has the shortest GC stop times,
>> but they're in the 6ms range which is way too high for serious real-time
>> audio work. Something like Lua might be better in this regard.
>> Does anyone know of any efforts to add real-time garbage collection to a
>> fast javascript interpreter?
> Not that I know of.  I'd just like to expand on this a bit.  It seems
> to be a common misunderstanding (particularly those discussing
> browser-based audio processing) that raw speed is all you need for
> doing real-time audio processing.  In fact, while speed obviously
> helps a lot, what's really important is time determinism.
> In a JITted language like JS, there are as far as I can tell two main
> sources of non-deterministic timing.  One is the garbage collector.
> The other is the JIT compiler.
> Letting GC aside, calling a function cannot be accomplished in a
> JIT-based language in a predetermined amount of time because a
> function call might either go to the interpreter (where it is
> deterministic but slow), or it might trigger the compiler (where
> compilation time depends on the function size).  After a section of
> code is compiled of course this non-determinism would theoretically go
> away, as long as the function is always called with the same type
> signature, but JITting a small function might take a ms or so.  It
> would be interesting to get data on how long the average JIT is.
> Real-time garbage collectors are uncommon but certainly possible.  A
> JS engine could be made to use the SND-RT collector perhaps.  A caveat
> though is that to make this work in practice you have to have an
> estimate of the upper bound on your heap.  If you need more heap than
> has been preallocated to the RT allocator, you've got to error out or
> reallocate the heap, so you're back to square one.  This could be
> problematic for web-oriented programming where this kind of
> information is unlikely to be available.
> I can imagine a theoretical real-time JIT engine, where each function
> is progressively compiled, allowing no more than a bounded amount of
> time to work on it at each function call.  This could be considered as
> part of the constant cost of calling a function.  Once it completes,
> the function call suddenly speeds up, which is fine.. the important
> thing is that it doesn't suddenly slow down.
> I don't know off hand of any work on this.
> Steve
> --
> dupswapdrop -- the music-dsp mailing list and website:
> subscription info, FAQ, source code archive, list archive, book reviews, dsp links
> http://music.columbia.edu/cmc/music-dsp
> http://music.columbia.edu/mailman/listinfo/music-dsp

More information about the music-dsp mailing list