Audio Engine v2 Feedback and Discussion Thread

Announcements
,
21

Hey, needed a couple of days to pull everything together. Leaving out what Audio Engine does for now, I find getting WebAudio started consistently in a WebXR session is approaching impossible. Some of this is beyond direct control, but some is. I will describe both.

==============================================================================
First, there is no “operational” indicator of an intention to use audio. The little thing to click only shows up AFTER an attempt to load/play a sound. Kind of too late for the first sound. There is an boolean Engine constructor option, audioEngine, but I could not find code that actually read it. If that switch could cause the UI to come up that would be good.

There are “tricks” that could be done like a “sacrificial sound” to prime the pump run to get the UI up, but that is best left for code that the programmer does not control.

==============================================================================
The XR part is when going from a web page with an active XR session ( & audioContext) directly to another page, which also immediately requests an XR session. There is a process browsers follow, which allow the new page to automatically start in a XR session without asking first. This is done using a term sessiongranted. This is described in GitHub - immersive-web/navigation: Repository for the discussion and research in to navigating from page to page whilst staying in immersive mode. Feature leads: Rik Cabanier and Brandon Jones.

Having the audio engine permission also be carried over is really important. I understand the restrictions on audio for the document world. For documents, it makes sense not to allow, without permission, sound to immediately start or allow page makers to do creepy stuff, like have a “check out our blue light specials” sound when mouse tracking indicates viewer is about to leave.

XR, or full page canvas pages, are more like TV, not documents. Imagine having to hit the un-mute button every time you changed the channel on your TV. That would old really fast.

To compound the problem, the viewer would then have to leave XR to see the audio permission button, or the page would have set up to deal with it itself. Even then the user would still have to do something. I am not sure what to do about this. Any suggestions?

22

This is an interesting subject, and you are correct in saying that some of it is beyond our direct control. I think browsers will need to make changes on their side to support keeping the audio context running across XR sessions, for example. While we wait for that to happen, we can look into fixing the other pain-points you bring up, so thanks for bringing it to our attention.

2 Likes
23

Thanks!

Minor note, keeping audio contexts open crossing pages is more than I think is needed. We just need the permission. Keeping contexts open across pages sounds messy. You can have more than one audio context, & they could all have stuff queued. The old page is dead. Postmortem utterances are probably not welcome.

2 Likes
24

It would be great to see a Node Audio Editor that would provide the ability to control the Web Audio API stream in a graphical format.

4 Likes
25

For me - a useful feature would be audio normalization. I was using Spatial Audio with sound files with different sound levels. Maybe that is too far out of scope. Would be a nice opt-in feature - or maybe like how post processing works on video to alter sounds.

2 Likes