5 ms·

Chrome’s web audio change is bad news

ricardobeat 8y ago
Its hard to have an opinion without any more details on how the change affects their product.
Bud 8y ago
Chrome's web audio change is very good news. There! I just supported my opinion just as well as this article supported Holovaty's. As an added bonus, I happen to be right. :)
delfaras 8y ago
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: [1] https://bugs.chromium.org/p/chromium/issues/detail?id=840866 https://bugs.chromium.org/p/chromium/issues/detail?id=840866
deleted 8y ago
[deleted]
georgemcbay 8y ago
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.
vincentriemer 8y ago
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 :(
RcouF1uZ4gsC 8y ago
>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.
alphabettsy 8y ago
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.

Its hard to have an opinion without any more details on how the change affects their product.

Bud 8y ago

Chrome's web audio change is very good news. There! I just supported my opinion just as well as this article supported Holovaty's. As an added bonus, I happen to be right. :)

delfaras 8y ago

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: [1] https://bugs.chromium.org/p/chromium/issues/detail?id=840866 https://bugs.chromium.org/p/chromium/issues/detail?id=840866

deleted 8y ago

[deleted]

georgemcbay 8y ago

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.

vincentriemer 8y ago

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 :(

RcouF1uZ4gsC 8y ago

>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.

alphabettsy 8y ago

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.