Hacker News new | ask | show | jobs
by joshstrange 1833 days ago
And I'm sure iOS Safari will still keep annoying restrictions on using it. I 100% understand the reasoning behind not allowing sound to play unless it's "user initiated" but it's really frustrating how small that window is and/or how you can't ask for that "permission". I have a web app that uses the camera for scanning (don't get me started on how Chrome/FF/etc on iOS can't use the camera for streaming) and in Safari I want to play little beep noise (toggleable on/off) after a successful scan but that's impossible.
4 comments

I just hacked together a workaround for this very thing myself. You can call play() in a click handler but immediately pause(), and then call play() again on the same Audio element later when your scanner succeeds.
The frustrating and unnecessary thing is the trend to completely intertwine permissions policy policy with the API.

If I can't play a sound, just make it browser feature -- let the web page call the APIs continue as normal, mute the tab, and browser notifies the user.

Instead, responsibility is pushed from the browser developers (small in number) every single web page developer to deal with rejections, prompt users, retry the request, and cover a bunch of edge cases that mostly they'll never see.

The policy ends up frozen in time around the needs of eg. 'desktop' and won't be able to adapt in future.

Also, the inevitible concern around fingerprinting a user based on the pattern or timing of rejected events.

Not sure about WebAudio spec specifically, but there are certainly places where media specs are basically just a reflection of "what Safari does" to work its way around corners its boxed itself into.

Once you play a sound, you’re allowed to keep playing sounds I think. Just play a silent track until sound is needed
Which, to the parent's point, makes the restriction itself pointless? It also seems like the kind of "workaround" that will one day be patched, and suddenly your app stops working.
I might have to try this again but I think I tried this at some point and I failed to get it working but it might have been making a mistake.
Some potential things to watch for:

- try not to obtain and initialize the audio context until the triggering event has occurred

- make sure the audio context + playback occurs directly as a result of the triggering event. If the event just sets some state, and then something else is periodically watching for that state to change, it may fail. A workaround here is to just mute+play some sound on that first tap, then you're good for any later Audio contexts created+initiated however you'd like.

Brings back memories of a web app I worked on (SpeakerBlast) that turned audio devices into one synced stereo. We used the silent file trick and had each audience members check into the Speakerblast (used that also to then to count and display number of connected speakers). We always had to find work around after Apple would change things up.