There's no rollback procedure in case a device switch fails right now,
nor does the code entrypoints that call the switching procedures wait
for resolution or failure before marking the new device as chosen. That
may cause inconsistent states in a couple of ways:
- No rollback: switch fails, audio is still on but no actual
microphone input is being transmitted
- Not waiting for resolutions: inconsistent chosen devices on failures
Device switching errors are also not surfaced to the end user
This commit:
- Adds device rollback and proper resolution/failure response
awaits to try and make the state a bit more consistent.
- Centralizes the input device switching code to be reused between
different bridges
- Centralizes device ID state management in audio-manager to try and
mantain them a bit more consistent across the board
- Surface device switching failures to the end user
- Guarantee device IDs are set to the session storage on all
appropriate scenarios
The new local echo view doesn't block the "Join audio" button while
awaiting for getUserMedia permission to be granted/denied. That may
cause unexpected behavior when unattentive users just click "Join audio"
without granting or denying gUM.
This commit accounts for gUM resolution when deciding whether to block
the "Join audio" button. It also includes an extra "isConnecting" check
to it to avoid spam-clicking issues.
removing border and implementing box-shadow
adding transparent border
passing styles to common buttons
adding secundary color to component
updating color components
The initial selected output device in AudioSettings could be the wrong one if
the user's session had an output device ID already stored, but is joining on a
new session. That would cause the remote-media tag not to be updated with the
correct output device ID when it should (the service.js change)
The issue is tackled by guaranteeing the output device ID is set on all ends
when AudioSettings/AudioModal mounts.
The initial selected input device in AudioSettings could be the wrong one if
- 1) gUM outputs an user-selected device rather than the default
- 2) no previous device was selected for that domain and the enumeration
list order caused the default not to be the first
The issue is tackled re-extracting the deviceId from an input stream if it
exists and making the DeviceSelector value follow what is defined in the client
(audio-manager) via a trackable prop
For scenarios where streams are produced in AudioSettings (local echo,
volume meter), force gUM resolution before devices are enumerated.
This effectively guarantees that all devices are present, labelled and
with deviceIds.
public.media.showVolumeMeterInSettings => public.media.showVolumeMeter
public.media.simplifiedEchoTest => public.media.localEchoTest.enabled
Initial hearing state can be configured in public.media.localEchoTest.initialHearingState
New features:
- A simplified echo test mode that only does a local loopback (instead of
going to FS and back)
- A volume meter for microphone streams to the AudioSettings view
Those two features are experimental and disabled by default; see
public.app.media.simplifiedEchoTest and public.app.media.showVolumeMeter configs
Collateral changes:
- fix: localize fallback device strings in AudioSettings/DeviceSelector
- Refactor on some media stream utils to be re-usable across components
- Refactor in AudioSettings to keep gUM #uses stable.
* TODO: need to pass streams through AudioManager to avoid the surplus gUM.
- fix(audio): drop ScriptProcessorNode usage (deprecated)
* Used in volume meter for tracking - use hark instead
