Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Web Audio API Is a W3C Recommendation

w3.org

Post reply on HN
Print view View original

21–30 of 33 posts

Re: Web Audio API Is a W3C Recommendation

#21

Post by wcarss »

joshstrange wrote: post #17
rubatuga wrote: post #16

Earlier quoted context omitted.

Once you play a sound, you’re allowed to keep playing sounds I think. Just play a silent track until sound is needed

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.

Re: Web Audio API Is a W3C Recommendation

#22

Post by claytongulick »

lasagna_coder wrote: post #13
chrislo wrote: post #5

Earlier quoted context omitted.

AudioWorklet (which allows you to work with audio sample-by-sample in a dedicated, high priority "thread") is available and works well in Firefox and the latest Safari. I haven't tried it in Edge, but I believe it's also working well.

Safari on iOS is still missing some important features that severely limits its usage.

This is true for many web features, including many basic PWA features like web push notifications, url capture, etc...

As a mobile first web developer, ios is the thing that's really holding us back.

The very frustrating thing about this is that the end user tends to blame the app, and there's not a good way to communicate to them "hey, we would totally do this, but mobile Safari has limited functionality and Apple won't allow other browsers to be installed"

Re: Web Audio API Is a W3C Recommendation

#23

Post by paul7986 »

joshstrange wrote: post #6

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 Safar…

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.

Re: Web Audio API Is a W3C Recommendation

#24

Post by [deleted] »

joshstrange wrote: post #6

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 Safar…

[deleted]

Re: Web Audio API Is a W3C Recommendation

#25

Post by zbuf »

joshstrange wrote: post #6

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 Safar…

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.

Re: Web Audio API Is a W3C Recommendation

#27

Post by rchaud »

NHQ wrote: post #26

Please please put the ScriptProcessorNode back in the spec.

Yes! I am using the WaveSurfer [0] library to visualize audio waveforms for a project, which uses this. It works, but Chrome always says 'ScriptProcessorNode is deprecated, use AudioWorkletNode instead'.

[0] https://github.com/katspaugh/wavesurfer.js

Re: Web Audio API Is a W3C Recommendation

#29

Post by chrisseaton »

rchaud wrote: post #28
chrisseaton wrote: post #8

What practical difference does the ceremony of ‘recommending’ make?

If it's added to the official spec, then browsers are expected to support that functionality out of the box, without needing polyfills.

> then browsers are expected to support that functionality out of the box

Does that work in practice? You can 'expect' all you want if they don't choose to implement it.

Post reply on HN