Stored input device IDs are not cleaned up whenever getUserMedia fails
with `NotFoundError` (i.e.: device not found). This causes a couple of
issues whenever skipEchoIfPreviousDevice is enabled:
- An unnecessary error screen if the user retries audio from scratch
(it should just go straight to the audio settings modal)
- A retry loop if no other devices are present in the system
Guarantee that stored input device IDs are cleared up whenever
getUserMedia fails with error name `NotFoundError`. This both the retry
loop and the unnecessary error screen.
`getUserMedia` is called by each audio bridge if it hasn't been
triggered during pre-flight screens. This ties gUM to the bridge's
negotiation timers and audio-manager's activation tracking, leading to
two issues:
- A gUM prompt left unanswered for over 30 seconds can cause an
incorrect 1010 (negotiation timeout) audio error.
- If `retryThroughRelay: true`, and a joinAudio timeout occurs due to an
unanswered gUM prompt, but the user responds while the system retries
the connection, it can create overlapping audio sessions, resulting in
mute state inconsistencies when `muteOnStart: true`.
This commit addresses these issues by moving gUM handling to the
audio-manager before any bridge action. This removes gUM from the
negotiation timeout trackers, ensuring that gUM errors are treated as
browser API errors (as expected).
Additionally, audio activation tracking in audio-manager has been updated
to exclude gUM times. Initially, gUM was included to catch unintended
browser-related gUM timeouts (e.g., Chrome bugs), but this skewed the
metric intended for tracking *negotiation times*. With this change,
`secondsToActivateAudio` will now focus solely on negotiation.
The check for whether an error code is deemed "retryable" in
sfu-audio-bridge's joinAudio code is reversed - which may cause
unwarranted audio retries on join failures.
Since only one of the retry points is broken, this is a rare issue.
For end users, the visible behavior is a duplicate error alert
since non-retryable errors are likely to fail again in subsequent
attempts
Fix the check to properly skip audio retries if the error is not
retryable.
* Update en.json
* Update settings.yml
* Create transcriptionLocale.ts
* Update component.tsx
* Update component.tsx
* Revert IN -> ID
Because it will be fixed in the main repository
* let -> const message
British -> GB
* Refactor audio captions messages and locales to fix issues reported by typescript code validation
---------
Co-authored-by: Ramón Souza <contato@ramonsouza.com>
The metadata is comming from server with { name: metaname, value: metavalue }, which is not compatible with
getFromMeetingSettings, so it's not reading corretly.
Convert it before storing.
- Avoids calling seekTo before the onStart event. In such case, React Player remounts the player, triggering a new onReady event, which was causing an infinite loop.
* Add: new connection close error messages
* Fix: TS type assertion
* Fix: Restore message description
* Add: Locale for server closed connection event
* move raise hand out of reactions bar
* adjust reactions bar border-radius
* adjust button background + remove custom icon
* fixing raise hand test
* skipping raise hand test
* fixed learning dashboaard test, flaky to notification test
---------
Co-authored-by: Gabriel Porfirio <gabrielporfirio1994@gmail.com>