We forgot to tell React that we need the audio renderer to react to changes in the set of MatrixRTC participants; instead we had it referencing rtcSession.memberships non-reactively.
Now, I'm not 100% confident that this is going to fix the "speaking from the void" issues observed in the wild, because I can't reproduce them and, in my testing, the InCallView component always seemed to be rendered redundantly when the MatrixRTC participants change, even though we hadn't explicitly stated that it needs to react. (This makes sense as we haven't memoized the component.) But it's worth a shot.
* Avoid reactivity bugs in how we track external state
Many of our hooks which attempt to bridge external state from an EventEmitter or EventTarget into React had subtle bugs which could cause them to fail to react to certain updates. The conditions necessary for triggering these bugs are explained by the tests that I've included.
In the majority of cases, I don't think we were triggering these bugs in practice. They could've become problems if we refactored our components in certain ways. The one concrete case I'm aware of in which we actually triggered such a bug was the race condition with the useRoomEncryptionSystem shared secret logic (addressed by a1110af6d5).
But, particularly with all the weird reactivity issues we're debugging this week, I think we need to eliminate the possibility that any of the bugs in these hooks are the cause of our current headaches.
* Reuse useTypedEventEmitterState in useLocalStorage
* Fix type error
This gives us the additional insurance of breaking the Safari media acquisition loop at the source by admitting that they can be spurious in practice. Safari, why!?
* Disable device switching when in controlled audio devices mode
* Temporarily switch matrix-js-sdk to robin/embedded-no-update-state
To allow us to test this change on Element X, which does not yet support the update_state action.
* Also add a check for controlled audio devices in useAudioContext
* use develop branch
* fix tests
---------
Co-authored-by: Robin <robin@robin.town>
Now that the toger5/add-room-key-fallback-on-encryption-manager-not-supported branch has been merged, we can reset to develop. (And need to, actually, because that branch is deleted.)
* Update RTCSession configuration to non deprecated names.
* bump js-sdk
* es2024 and array buffer adaptions
* Alternative without `createKeyMaterialFromBuffer`
* Add custom audio renderer to only render joined participants & add ios earpice workaround
fix left right to match chromium + safari
(firefox is swapped)
earpice as setting
Simpler code and documentation
The doc explains, what this class actually does and why it is so complicated.
Signed-off-by: Timo K <toger5@hotmail.de>
use only one audioContext, remove (non working) standby fallback
* Add tests
* use optional audio context and effect to initiate it + review
* Better logs for connection/component lifecycle
* fix: `AudioCaptureOptions` was causing un-necessary effect render
AudioCaptureOptions was a different object but with same internal values, use directly deviceId so that Object.is works properly
* fix: Livekit openned connection leaks
* review: rename to AbortHandles
* review: rename variable
---------
Co-authored-by: Timo <toger5@hotmail.de>
* Only show to device encryption label if developer mode on
* Add tests for developer mode to device label
---------
Co-authored-by: Timo <toger5@hotmail.de>
* Fix to-device encryption info label
The label was shown also without checking that we use PerParticipantE2EE. Which is a prerequisite for toDevice transport. As a result the label was shown when not desired.
* rename: useLiveKit -> useLivekit
* make the settings naming consistent
