seamless switching of channels without delay

problem

• fast switching of interpretation channels is essential when interpreting multiple languages within one conversation
• even with fast TURN-Setup the connection times differ between users and are not constant or instant

solution

• to ensure seamless switching, we could cache the interpretation channels for the interpreters
  • participants excluded
• keep the channel active after first switching to an (speak-into) interpretation channel and reuse when coming back later
• use mute-controls like with the floor channel to

i have split this from the delay ticket #115

changed milestone to %WE update 21-5

mentioned in issue #115

marked this issue as related to #115

changed the description

I have just deployed a test version for this issue on dev. It supports multiple translator bridges which are now opened once the interpreter joins the channel (which may lead to a slight increase in loading time when joining a channel for the first time), and are left open until the interpreter leaves the conference. Instead of calling join/exit on the audio bridge, switching is now done by enabling/disabling MediaStreamTrack on the corresponding bridge, speeding up subsequent channel switches significantly.

Did some more testing and tagged the version: https://git.fairkom.net/chat/fairblue/-/tags/multiple_translation_channels

i can confirm this in my testing with virtaudio devices we will do interactive testing soon

@martin.klampfer we tested this with professional interpreters and it works

there are still problems and the interpreters gave some feedback. see the protocol (german) https://git.fairkom.net/chat/fairblue/-/wikis/test-on-2021-12-08

mentioned in issue #133

marked this issue as related to #133

• this is confirmed in our working on 2021-12-08 https://git.fairkom.net/chat/fairblue/-/wikis/test-on-2021-12-08
• followup feature: #133

closed

added Feature label

marked this issue as related to #141

marked this issue as related to #131 (closed)

removed the relation with #131 (closed)