(In reply to Adam from comment #1)
> It also does not work for remote streams.
On iOS, AudioContext needs a user gesture.
Can you retry by starting AudioContext as part of user gesture?
We should probably remove that restriction when getUserMedia is on.

> On iOS, AudioContext needs a user gesture.
Is it intended that AudioContext needs a user gesture even when there is no audio output? Being able to visualize the audio volume would be especially useful in exactly this use case when audio output is blocked.

(In reply to Andrew Morris from comment #3)
> > On iOS, AudioContext needs a user gesture.
>
> Is it intended that AudioContext needs a user gesture even when there is no
> audio output? Being able to visualize the audio volume would be especially
> useful in exactly this use case when audio output is blocked.
Good point, maybe the restriction should be targeted at the audio output.

We hit this bug as well, where we want to do an automated microphone check for users on their way into a conversation. Our code looks something like this:
function handleUserClick() {
return mediaDevicesService
.getUserMedia(constraints)
.then(mediaStream => {
this.setState({ mediaStream });
})
.then(() => enumerateDevices())
.then(() => verifyMicrophoneWorks(this.state.mediaStream.stream))
.then(isMicrophoneWorking =>
this.props.updateMicStatus(isMicrophoneWorking)
)
.catch(error => <GetUserMediaErrorFeedback error={error} />);
}
This all happens in a single promise-chain, but because only the original button click is triggered as a user action, the audio context checking fails, even if all we do is check the getByteFrequencyData, and no audio is actually playing.
It would be great if we were allowed to play audio/handle AudioContext once getUserMedia permission is granted for the page for that session.

Sorry for the late reply youenn. We decided to refactor as more browsers are adopting autoplay restrictions now, and we don't want to take the chance that this causes issues in the future. All of our AudioContext's are triggered by a user action now.

(In reply to daginge from comment #12)
> Sorry for the late reply youenn. We decided to refactor as more browsers are
> adopting autoplay restrictions now, and we don't want to take the chance
> that this causes issues in the future. All of our AudioContext's are
> triggered by a user action now.
No problem daginge.
I believe we could tackle that issue by introducing some WebAudio specific constructs that would allow analyzing audio but not producing any audio.
In that case, we could bypass autoplay restrictions.