Scheduled sends are throttled when page isn't front tab

[nfroidure]

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]

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]

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

[nfroidure]

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#72
WebAudio/web-midi-api#76

[cwilso]

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#72WebAudio/web-midi-api#72
WebAudio/web-midi-api#76WebAudio/web-midi-api#76

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

[nfroidure]

I added the PageVisibility test to try to avoid the problem as announced, here is the commit:
nfroidure/midiplayer@59759ea
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]

Should really use the worker settimeout workaround here.