When using enableWebAudio, if a user joins a meeting and Chrome rejects their mic access due to needing page interaction (ie: MEI/engagement score rejection), "The AudioContext was not allowed to start." errors are fired and the user's microphone doesn't recover.
Join the session in Chrome in a way that triggers the gesture-required state (eg: close all windows and relaunch with --user-gesture-required). Do everything you can to avoid accidentally interacting with the page until the app has connected.
Apologies if I've misused MEI here - bear with me...
Our application attempts to start a meeting as soon as users open the page (trying to reduce friction with users), so we have some issues with user gestures being required to kick off audio on the page.
On Firefox we've been able to work around this by detecting delays in the start process - IIRC audioVideo.startLocalVideoTile() holds up the process, and if this takes more than a couple of seconds we can show a prompt for the user to click, which allows the AV devices to start and we can continue joining the meeting.
On Chrome, however, this delay doesn't seem to happen, and I've been unable to find a way of programmatically detecting this failure. Things seem to recover pretty well normally, but when enableWebAudio is set to true (ie: to allow us to turn on Voice Focus), it appears that the web audio context gets stuck in a failed state, and I can't spot a way to identify this in order to remedy it. This assumption is based on The AudioContext was not allowed to start. It must be resumed (or created) after a user gesture on the page. errors appearing in the logs, fired from DefaultDeviceController.ts.
From a hunt through DefaultDeviceController, handling of the suspended state in there doesn't look particularly thorough, so the issue might be in there, I guess? We've had similar issues with our previous provider (Twilio) - but were able to create our own separate media context and detect the failure there (polling until the audioContext.state value changes from suspended to running, and taking action based on that. I'm currently trying to adapt this method as a workaround, but I'm assuming based on other behaviours that Chime would be expected to recover automatically in this situation?
For context, in development I'm currently manually stopping/restarting the Audio Input which resolves it, but without a way of identifying this state, we can't give the user anything useful to go on:
What happened and what did you expect to happen?
When using enableWebAudio, if a user joins a meeting and Chrome rejects their mic access due to needing page interaction (ie: MEI/engagement score rejection), "The AudioContext was not allowed to start." errors are fired and the user's microphone doesn't recover.
Have you reviewed our existing documentation?
Reproduction steps
Amazon Chime SDK React Components Library version
3.8.0
What browsers are you seeing the problem on?
Chrome
Browser version
127.0.2
Device Information
Win11 Desktop
Meeting and Attendee ID Information.
No response
Browser console logs
focusgroups.localhost.visionslive.com-1720105221949.log
Add any other context about the problem here.
Apologies if I've misused MEI here - bear with me...
Our application attempts to start a meeting as soon as users open the page (trying to reduce friction with users), so we have some issues with user gestures being required to kick off audio on the page.
On Firefox we've been able to work around this by detecting delays in the start process - IIRC audioVideo.startLocalVideoTile() holds up the process, and if this takes more than a couple of seconds we can show a prompt for the user to click, which allows the AV devices to start and we can continue joining the meeting.
On Chrome, however, this delay doesn't seem to happen, and I've been unable to find a way of programmatically detecting this failure. Things seem to recover pretty well normally, but when enableWebAudio is set to true (ie: to allow us to turn on Voice Focus), it appears that the web audio context gets stuck in a failed state, and I can't spot a way to identify this in order to remedy it. This assumption is based on
The AudioContext was not allowed to start. It must be resumed (or created) after a user gesture on the page.errors appearing in the logs, fired from DefaultDeviceController.ts.From a hunt through DefaultDeviceController, handling of the
suspendedstate in there doesn't look particularly thorough, so the issue might be in there, I guess? We've had similar issues with our previous provider (Twilio) - but were able to create our own separate media context and detect the failure there (polling until the audioContext.state value changes from suspended to running, and taking action based on that. I'm currently trying to adapt this method as a workaround, but I'm assuming based on other behaviours that Chime would be expected to recover automatically in this situation?For context, in development I'm currently manually stopping/restarting the Audio Input which resolves it, but without a way of identifying this state, we can't give the user anything useful to go on:
Sorry that the report is a bit of a mess - give me a shout if there's any additional information that would help 😄