47018e5a65
When `muteOnStart=true`, the initial local mute state in AudioManager is desynced from the server. This issue stems from two recent changes: - Decoupling voice activity updates from the main user_voice subscription, which introduced an implicit muted state placeholder value of true instead of false. See user_voice_activity's DB schema propagation rules. - Introduction of dialplan-level muteOnStart, muting channels on creation rather than after. Without properly updating AudioManager's `isMuted` placeholder, no user_voice_activity update triggers *when joining audio* with muteOnStart=true, causing two issues: - Sender tracks are not locally muted on audio join. - Opening the audio settings modal while muted will cause the microphone to be incorrectly *unmuted* once it's closed (first try only). This fix sets AudioManager's `isMuted` placeholder to true, matching the server. Additionally: - Enforce the local mute state before joining audio to ensure the desired sender track state. Should make this a bit more future proof. - Track `user_voice_activity` before joining audio (rather than after) to avoid race conditions. - Clean up `AudioManager.init` (loadBridges no longer returns a promise etc). |
||
---|---|---|
.. | ||
components | ||
core | ||
hooks | ||
services | ||
stylesheets/styled-components | ||
Types |