
Chrome’s web audio change is bad news - collinmanderson
http://www.holovaty.com/writing/chrome-web-audio-change/
======
delfaras
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)

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

------
Bud
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. :)

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

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

