Google Chrome has changed the way audio playback works, such that no audio will be played unless a user interacts with the web page first. Read more in their overly cutesey announcement. (Note to Google: using meme images in announcements like this is not a good look.)
This change broke Soundslice audio playback for a short while, until one of our customers notified us. Since then, I’ve been following the web-developer response with great interest. This bug report in the Chromium bug tracker has materialized as a place for developers to argue against the change.
I’ve just posted a comment there, and I feel strongly enough about this that I wanted to post it here to my blog as well:
Adding to the many excellent sites mentioned here — my company Soundslice makes a web-based sheet-music viewer that syncs audio/video with music notation (example). We’ve also been affected by this poorly thought-out Chrome change.
We’ve fixed it by adding hacky workarounds for Chrome, but this is a big step backward for web audio.
To anticipate an argument from the Chrome team that “only fun hacks, games and art projects are affected” — that is NOT the case. Soundslice is a real business with paying customers.
We knew it was risky to build a business on top of the Web Audio API when we first launched support for it in 2014, but we expected browser support and user experience would improve over time. Unfortunately it’s been a consistently rocky road since then. The draconian web audio limitations on iOS — basically the same as this new Chrome behavior — have been a disaster, and Chrome never should have followed in Apple’s footsteps.
The good news is that nothing is set in stone, and the Chrome team can undo this change to show competence and goodwill.
Finally, an existential question for the Chrome team: do you want the web to continue ceding mindshare to native apps? If so, please continue neutering what we web developers can do, and please continue encouraging sub-par experiences for end users.
Comments
Posted by Steven Estrella on May 10, 2018, at 11:32 a.m.:
I agree that this change to Chrome is badly done. The problem is that if an AudioContext is created when the page loads (from a direct URL request), then the AudioContext is automatically paused even if that AudioContext is not currently playing audio. That breaks a lot of code even in games where the user is required to click something before audio playback begins. So the fix Chrome implemented goes beyond stopping autoplay. Now I have to add context.resume() to the play button code in every page. ugh!
Posted by ChatApp on May 23, 2018, at 6:02 a.m.:
I'm all for letting the user block autoplay, I'm just not for Chrome's solution.
Example where the change sucks. Chat apps. Chat apps want to make a "ping" sound when a new message arrives. Can't unless the user interacts. I reboot my machine and or log out. I restart Chrome, it reloads tabs, tabs that have my chat sessions in them. This change basically means I have to go to each tab and click something before I'll start getting notification sounds.
You might say a solution is to use the notification API but the notification API has other issues. One is that without warning message contents gets displayed in the notification. That content might not be something I want someone else to see so I have chosen not to opt into the notification API instead preferring just a sound so I can choose if it's safe to view.
A better solution, at least for chat, is to let the user whitelist the page. That's not an option with Chrome's new system.
Comments have been turned off for this page.