surikov / webaudiofont

Use full GM set of musical instruments to play MIDI and single sounds or effects. Support for reverberation and equaliser. No plugins, no Flash. Pure HTML5 implementation compatible with desktop and mobile browser. See live examples.
https://surikov.github.io/webaudiofont/
GNU General Public License v3.0
891 stars 92 forks source link

Continue playing even if the browser tab is not in focus #92

Closed page200 closed 1 year ago

page200 commented 1 year ago

Is there a way to continue playing the music even if the browser tab is not in focus? Maybe by using some kind of more aggressive playback technology.

surikov commented 1 year ago

Browser manufacturers force background pages to reduce resource consumption. This is the rule for all browsers. I don't want to fight browser makers.

alfedukovich commented 1 year ago

Use setTimeout or setInterval to queue ahead until the queue finishes playing. Then playback won't stop when you switch tabs. code code

page200 commented 1 year ago

Thank you, that example indeed works and uses setInterval, and the variant with setTimeout works as well. setInterval or setTimeout seem nice for auto-repeating the song for an unlimited number of times.

On the other hand, for each playthrough of a song, I wonder whether anything speaks against simply setting stepDuration to the song duration, i.e. queueing the entire song via queueWaveTable() at once. The notes are then scheduled here via the start() method of an AudioBufferSourceNode, so the browser makers decide what to do with that, and we're not fighting them. (For now. :))

page200 commented 1 year ago

Setting a long stepDuration works in Firefox and for some MIDI files in Chrome. For other MIDI files in Chrome, the audio stops after a second. Maybe Chrome is stupid in that it focuses on computing something too early for future sounds instead of playing imminent sounds as intended (like Firefox does).

Instead of a long stepDuration, what seems to work is to call each step with window.setTimeout instead of window.requestAnimationFrame. Both are unnecessarily resource-intensive except if setTimeout takes into account when the next note will actually play instead of getting called every 10 milliseconds.