You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#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.
The text was updated successfully, but these errors were encountered:
jbg
changed the title
Allow enabling
Per-conference "only forward audio packets of the loudest speakers"
Jul 12, 2021
#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.
The text was updated successfully, but these errors were encountered: