W3C home > Mailing lists > Public > public-audio@w3.org > April to June 2012

Re: Timing limitations when programming MIDI with Javascript

From: Chris Wilson <cwilso@google.com>
Date: Tue, 5 Jun 2012 10:32:27 -0700
Message-ID: <CAJK2wqWOfXM+ahnDc2nBDBn3hCf34K9JFpJkMY99-yB3Q8mbuw@mail.gmail.com>
To: James Ingram <j.ingram@netcologne.de>
Cc: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>, public-audio@w3.org
On Tue, Jun 5, 2012 at 6:48 AM, James Ingram <j.ingram@netcologne.de> wrote:

> This is actually where the timestamps shine. You can have a clock
>> interval, like 200 milliseconds, where you proceed reading a list of events
>> and queue the events that are going to occur in the following 200ms, and
>> send them to be played at respective times, without a need for individual
>> setTimeouts for each event which is very CPU-intensive, and not to mention
>> that events that are supposed to occur at the same time don't necessarily
>> do so, maybe due to GC or rendering or whatever is blocking the next
>> timeout.
> I think the penny just dropped! Thanks for your patience. Is this actually
> working in Midibridge? Perhaps there should be an example in the docs...

No.  MIDIBridge doesn't currently have timestamps, I don't believe.

> 35 seconds is quite a long time to read a score (our JS audio codecs can
>> read complete songs in a matter of seconds), I suggest reading the score in
>> a worker thread using a JS-based DOM library to avoid the overhead that
>> might come with browser built-in DOM.
> Am looking into this too, of course.

+1 to what Jussi said.  35 seconds is far longer than I'd expect this kind
of code to take, even without a worker thread and JS-based DOM.

Received on Tuesday, 5 June 2012 17:33:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:04 UTC