Sounds fair enough. We have a new autoplay policy in the making that should fix this. Though, in the meantime, would it work to "bless" the video element when you get a user gesture?

In order to overcome the current limitation, for now, we do on "user gesture" we do 'audiocontext creation' + 'audio medialElement' play() but with gain node with value of 0, and then set medial currenttime and volume when the real "play" is needed. that "all-one-work" gesture works afaict (not ideal though)

( Would love official doc link the on (new) autoplay policy in the making !)

see  bug 715049 

Just FYI, Posting there, we released the sound feature where we use Webaudio + 3D positionning
https://sketchfab.com/models?&features=sound&sort_by=-viewCount

Webaudio api is very good, and very well implemented, hardly had to code anything about audio and 3D. 

In fact, most of the code is audiocontext (release/allocate) handling to overcome the 6 limit, and handling of "user gesture" auth. As Both are entwined (As I release audiocontext on "tab hidden" and ask user again on "tab visible"). Also Our 3d viewer is to be embedded as iframe on web page, and webpage can have more than 6 embeds, which leads to "complex technical error message" for users like some ("please "exit" other embeds so that sound can play here")

Thanks for all the bug fixes, and please ask/email if you want pro account to test multiples sound, as free user are limited to 1 sound. :)

Any news on that ?
And the question in https://bugs.chromium.org/p/chromium/issues/detail?id=715049#c32 

I'd really like a simple synchronous API to get authorization and or reading authorization status 

Rationale is that milliseconds at a web page start are costly (need that info as fast as possible which is js parse time), and current code makes for async + exception throwing not ideal at all for optimisations...

This is something we are looking at.

This should be fixed with the new autoplay policy in M66.