Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

let web-decker scripts play audio in the background #86

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

easrng
Copy link

@easrng easrng commented Apr 2, 2024

when a tab is in the background, requestAnimationFrame gets seriously throttled
if a script in a deck like jankytunes is playing sound that messes it up
so we should use setTimeout instead, which isn't throttled if audio is playing

@easrng
Copy link
Author

easrng commented Apr 2, 2024

this isn't perfect, there's one delay when you tab out as the pending animationframe gets delayed before it switches to timeouts for new frames until the user comes back

@JohnEarnest
Copy link
Owner

JohnEarnest commented Apr 2, 2024

Hm. I tried this patch out in several versions of Safari, Chrome, and Firefox, and while it doesn't cause any harm it doesn't actually appear to make any difference on Safari or Chrome.

@easrng
Copy link
Author

easrng commented Apr 3, 2024

Oh, I see the problem!

@JohnEarnest
Copy link
Owner

I did some experiments with both the above patch and a simplified version which entirely dispenses with requestAnimationFrame/onvisibilitychange and exclusively uses setTimeout().

In Chrome, requestAnimationFrame() and setTimeout() appear to behave identically; audio plays at the normal rate irrespective of page focus even with the simplified approach.
In Firefox, setTimeout() has a noticeably less consistent tempo on slower machines, but it does continue to trigger at nearly the normal rate when the page loses focus.
In Safari, setTimeout() is severely throttled when the page is not focused; it plays about 1 note every 2 seconds.

I'm not really thrilled about implementing features which work on Chrome but perform worse or not at all on other browsers.

@easrng
Copy link
Author

easrng commented Apr 4, 2024

hmm, it occurs to me that it might be a better idea to check how long a tick took and subtract that from the setTimeout delay, since i'm pretty sure that's effectively what requestanimationframe does (but with a variable refresh rate)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants