Jitsi Videobridge is a WebRTC compatible video router or SFU that lets build highly scalable video conferencing infrastructure (i.e., up to hundreds of conferences per server).
1677 adds the very nice feature to only forward audio for the loudest speakers, making very large audio calls possible. However, there are some deployments using JVB with custom frontends where this implementation won't work. An example is where users are moving around some spatial area (e.g. a virtual world), and they should only hear the participants closest to them. At the moment this is implemented by doing the mixing on the client side, which is based on the assumption that JVB forwards all audio all the time, which makes it incompatible with the feature in #1677.
What would be the best approach to enable/disable this feature on a per-conference basis ("best" in terms of being consistent with other features that are enabled per-room)?
Would there be any interest in a patch to make clients able to signal (presumably via Colibri) the endpoints they'd like to receive audio from, in a similar manner to the existing mechanisms for doing that with video?
We're happy to do implementation work for either or both the above; would just like to ensure that we don't duplicate any effort and that our work would be considered for merging once done.
You might be interested to have a look at what @hasevr did in https://github.com/BinauralMeet/jitsi-videobridge
basically I added new setPerceptibles command so frontend can require specific streams
1677 adds the very nice feature to only forward audio for the loudest speakers, making very large audio calls possible. However, there are some deployments using JVB with custom frontends where this implementation won't work. An example is where users are moving around some spatial area (e.g. a virtual world), and they should only hear the participants closest to them. At the moment this is implemented by doing the mixing on the client side, which is based on the assumption that JVB forwards all audio all the time, which makes it incompatible with the feature in #1677.
We're happy to do implementation work for either or both the above; would just like to ensure that we don't duplicate any effort and that our work would be considered for merging once done.