While I agree that the article does a poor job at explaining why they are affected by the changes in the Audio API, I advise you to visit the chromium bug tracker issue [1] and check for yourself how many user/libraries/pages are affected by the problem:
The blog post should do a better job of explaining the real issue. It seems like the REAL issue is that Chrome's implementation of this feature is lackluster because when the audio fails to play it does so with no notification to the user.
A better implementation would be if when the website first tried to play audio sans interaction, a permission request was made like the ones that show up for websites that want to do desktop notifications, etc. That way the failure isn't silent and the user has some control over the option to allow or deny the permission on a site-by-site basis.
Having said that, I find that websites auto-playing audio is such a nuisance these days that I'd personally selfishly allow every project/business that relies on the ability to just die and not really shed a tear if there was some reason the Chrome team couldn't come up with a better implementation.
Chrome (and the web platform in general) has been moving to this model of features/APIs needing to be called "as a result of a user interaction". This sounds reasonable in theory, but like I recently realized, chrome cannot detect if a call was in a response to a user gesture 100% of the time.
I've been experimenting with an architecture where all app logic lives in a web worker, so in order to respond to events, the event gets handled on the main thread and forwarded to the worker, where it then triggers app logic which sends commands back to the main thread.
Problem is, once you cross a thread boundary, you lose all the context which classifies your calls as "in result of a user gesture", so you need to resort to hacky workarounds that force you to keep your app logic on the main thread :(
>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.
Maybe native apps should be considered more often.
These changes were caused by too many sites auto playing audio, obviously there are circumstances where this is desireable, but I’d rather always have to hit play.
The article doesn’t really explain why it’s such an issue for them though.
8 comments
[ 4.9 ms ] story [ 25.8 ms ] threadThere! I just supported my opinion just as well as this article supported Holovaty's.
As an added bonus, I happen to be right. :)
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=840866
A better implementation would be if when the website first tried to play audio sans interaction, a permission request was made like the ones that show up for websites that want to do desktop notifications, etc. That way the failure isn't silent and the user has some control over the option to allow or deny the permission on a site-by-site basis.
Having said that, I find that websites auto-playing audio is such a nuisance these days that I'd personally selfishly allow every project/business that relies on the ability to just die and not really shed a tear if there was some reason the Chrome team couldn't come up with a better implementation.
I've been experimenting with an architecture where all app logic lives in a web worker, so in order to respond to events, the event gets handled on the main thread and forwarded to the worker, where it then triggers app logic which sends commands back to the main thread.
Problem is, once you cross a thread boundary, you lose all the context which classifies your calls as "in result of a user gesture", so you need to resort to hacky workarounds that force you to keep your app logic on the main thread :(
Maybe native apps should be considered more often.
The article doesn’t really explain why it’s such an issue for them though.