search

cwilso / WebMIDIAPIShim

Polyfill using the Jazz NPAPI MIDI plugin to implement the Web MIDI API on Mac and Windows.
380 stars 53 forks source link

Scheduled sends are throttled when page isn't front tab #33

Open nfroidure opened 10 years ago

nfroidure commented 10 years ago

Hi,

I made a simple MIDI Karaoke player : http://karaoke.insertafter.com/

The problem i noticed is that when i go to another tab, the song slows down. I think that it's due to the fact that the browser limits setTimeouts for inactive tabs.

Are there a way to avoir that ? Will make the WebMIDIAPI available in WebWorkers avoid the problem ?

cwilso commented 10 years ago

Yes, that's the problem with the polyfill - it has to use setTimeout to do timed sends, and setTimeout is throttled by the browser. The natively-implemented Web MIDI API (in Chrome Canary under a flag now) should not have this problem, however. Unfortunately, I don't think I can get the extension used by the polyfill to work inside a worker, so I'd have to do a multi-stage system, using a worker only to get the setTimeout calls on time but then just postMessage()ing back to the main thread to dispatch. I'll keep this on the stack, but I doubt I'll get to it soon in the polyfill.

nfroidure commented 10 years ago

I'll test with Chrome Canary and give the feedback here.

nfroidure commented 10 years ago

Ooops, not available for my platform :( (Linux).

Anyway, as concluded in the issues listed above, a MIDI player will systematically have to rely on setTimeout to send MIDI events progressively to the player. That's what i did with MIDIWebKaraoke. If you use play/pause buttons you'll notice the short delay i had to set up (currently 600ms).

I assume the only way to avoid those holes will be to use the Page Visibility API to increase this delay when the page is hidden (https://developer.mozilla.org/en-US/docs/Web/Guide/User_experience/Using_the_Page_Visibility_API). It make senses since the user will not be able to pause the play when the page is hidden.

I'll update the code later and up this thread. I assume you have a Macn, will you accept to give a try and tell me the result ?

https://github.com/WebAudio/web-midi-api/issues/72 https://github.com/WebAudio/web-midi-api/issues/76

cwilso commented 10 years ago

sure.

On Sun, Sep 15, 2013 at 9:42 AM, Nicolas Froidure notifications@github.comwrote:

Ooops, not available for my platform :( (Linux).

Anyway, as concluded in the issues listed above, a MIDI player will systematically have to rely on setTimeout to send MIDI events progressively to the player. That's what i did with MIDIWebKaraoke. If you use play/pause buttons you'll notice the short delay i had to set up (currently 600ms).

I assume the only way to avoid those holes will be to use the Page Visibility API to increase this delay when the page is hidden ( https://developer.mozilla.org/en-US/docs/Web/Guide/User_experience/Using_the_Page_Visibility_API). It make senses since the user will not be able to pause the play when the page is hidden.

I'll update the code later and up this thread. I assume you have a Macn, will you accept to give a try and tell me the result ?

WebAudio/web-midi-api#72https://github.com/WebAudio/web-midi-api/issues/72 WebAudio/web-midi-api#76https://github.com/WebAudio/web-midi-api/issues/76

— Reply to this email directly or view it on GitHubhttps://github.com/cwilso/WebMIDIAPIShim/issues/33#issuecomment-24474869 .

nfroidure commented 10 years ago

I added the PageVisibility test to try to avoid the problem as announced, here is the commit: https://github.com/nfroidure/MIDIPlayer/commit/59759ea9f6a77c0c0491b5fd18a19eb2a70127f3 And here is a test URL: http://rest4.org/github/nfroidure/MIDIPlayer/master/tests/index.html

Let me know if the problem still occurs.

cwilso commented 9 years ago

Should really use the worker settimeout workaround here.