[jitsi-dev] jitsi videobridge audio mixing? supported? by default?


#1

Hi,

While developing an application that uses jitsi videobridge I have noticed
that the video streams are relayed fine but the audio is not delivered
properly.

In the implementation it is assumed that the bridge by default mixes audio
(in contrast to video which is relayed). The SSRC of each bridge audio
channel is signaled to the corresponding participant but the audio SSRC-s
announced by the client are not propagated to all other participants (just
to the bridge itself). My understanding is that this would have been
sufficient if the above assumption is correct i.e. the bridge does actually
mix the audio streams. Please confirm!

However, observing the actual results I can infer that the videobridge just
relays the audio streams as it does with video.

Having this in mind could you please provide some input on the following:

1. Does the latest videobridge support audio mixing? If yes, is this the
default behavior or it should be explicitly requested - e.g. by
setting rtp-level-relay-type='mixer'
attribute on the audio channel, etc. The colibri protocol specification (
https://jitsi.org/colibri/) is not quite clear for me in this area...

2. In jitsi meet the audio is relayed. Am I correct? Why it is not mixed?
What are the benefits of having relayed audio channels - significant
performance improvements? Will the dominant speaker recognition still work
if the audio is mixed?

Thanks for all your support.

Regards,
Mihail


#2

Hey Mihail,

Answers inline:

Hi,

While developing an application that uses jitsi videobridge I have noticed
that the video streams are relayed fine but the audio is not delivered
properly.

In the implementation it is assumed that the bridge by default mixes audio
(in contrast to video which is relayed). The SSRC of each bridge audio
channel is signaled to the corresponding participant but the audio SSRC-s
announced by the client are not propagated to all other participants (just
to the bridge itself). My understanding is that this would have been
sufficient if the above assumption is correct i.e. the bridge does actually
mix the audio streams. Please confirm!

However, observing the actual results I can infer that the videobridge
just relays the audio streams as it does with video.

Having this in mind could you please provide some input on the following:

1. Does the latest videobridge support audio mixing?

Yes.

If yes, is this the default behavior

No

or it should be explicitly requested - e.g. by setting rtp-level-relay-type='mixer'
attribute on the audio channel, etc.

Yes

The colibri protocol specification (https://jitsi.org/colibri/) is not
quite clear for me in this area...

2. In jitsi meet the audio is relayed. Am I correct?

Yes

Why it is not mixed? What are the benefits of having relayed audio
channels - significant performance improvements?

Yes. Very significant. To the point that we are considering abandoning
mixer support in the bridge.

Will the dominant speaker recognition still work if the audio is mixed?

Not sure. Give it a try.

Emil

···

On Wednesday, August 12, 2015, Mihail Bratoev <mbratoev@gmail.com> wrote:

Thanks for all your support.

Regards,
Mihail

--
sent from my mobile


#3

A question inline

Hey Mihail,

Answers inline:

Hi,

While developing an application that uses jitsi videobridge I have
noticed that the video streams are relayed fine but the audio is not
delivered properly.

In the implementation it is assumed that the bridge by default mixes
audio (in contrast to video which is relayed). The SSRC of each bridge
audio channel is signaled to the corresponding participant but the audio
SSRC-s announced by the client are not propagated to all other participants
(just to the bridge itself). My understanding is that this would have been
sufficient if the above assumption is correct i.e. the bridge does actually
mix the audio streams. Please confirm!

However, observing the actual results I can infer that the videobridge
just relays the audio streams as it does with video.

Having this in mind could you please provide some input on the following:

1. Does the latest videobridge support audio mixing?

Yes.

If yes, is this the default behavior

No

or it should be explicitly requested - e.g. by setting rtp-level-relay-type='mixer'
attribute on the audio channel, etc.

Yes

The colibri protocol specification (https://jitsi.org/colibri/) is not
quite clear for me in this area...

2. In jitsi meet the audio is relayed. Am I correct?

Yes

Why it is not mixed? What are the benefits of having relayed audio
channels - significant performance improvements?

Yes. Very significant. To the point that we are considering abandoning
mixer support in the bridge.

Does jitsi-meet support any mobile clients? How many audio streams have
you found are reasonable to send to mobile? That's an area we've seen
sending a pre-mixed stream is beneficial.

···

On Wed, Aug 12, 2015 at 6:19 AM, Emil Ivov <emcho@jitsi.org> wrote:

On Wednesday, August 12, 2015, Mihail Bratoev <mbratoev@gmail.com> wrote:

Will the dominant speaker recognition still work if the audio is mixed?

Not sure. Give it a try.

Emil

Thanks for all your support.

Regards,
Mihail

--
sent from my mobile

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#4

Yep, makes sense. So does the bridge allow an independent last-n setting
for audio so that, even in a large conference, only a subset of audio
streams would be forwarded?

···

On Wed, Aug 12, 2015 at 11:32 AM, Emil Ivov <emcho@jitsi.org> wrote:

Hey Brian,

On Wed, Aug 12, 2015 at 10:58 AM, Brian Baldino <brian@highfive.com> > wrote:
> A question inline
>
> On Wed, Aug 12, 2015 at 6:19 AM, Emil Ivov <emcho@jitsi.org> wrote:
>>
>> Hey Mihail,
>>
>> Answers inline:
>>
>> On Wednesday, August 12, 2015, Mihail Bratoev <mbratoev@gmail.com> > wrote:
>>>
>>> Hi,
>>>
>>> While developing an application that uses jitsi videobridge I have
>>> noticed that the video streams are relayed fine but the audio is not
>>> delivered properly.
>>>
>>> In the implementation it is assumed that the bridge by default mixes
>>> audio (in contrast to video which is relayed). The SSRC of each bridge
audio
>>> channel is signaled to the corresponding participant but the audio
SSRC-s
>>> announced by the client are not propagated to all other participants
(just
>>> to the bridge itself). My understanding is that this would have been
>>> sufficient if the above assumption is correct i.e. the bridge does
actually
>>> mix the audio streams. Please confirm!
>>>
>>> However, observing the actual results I can infer that the videobridge
>>> just relays the audio streams as it does with video.
>>>
>>> Having this in mind could you please provide some input on the
following:
>>>
>>> 1. Does the latest videobridge support audio mixing?
>>
>>
>> Yes.
>>
>>>
>>> If yes, is this the default behavior
>>
>>
>> No
>>
>>>
>>> or it should be explicitly requested - e.g. by setting
>>> rtp-level-relay-type='mixer' attribute on the audio channel, etc.
>>
>>
>> Yes
>>
>>>
>>> The colibri protocol specification (https://jitsi.org/colibri/) is not
>>> quite clear for me in this area...
>>>
>>> 2. In jitsi meet the audio is relayed. Am I correct?
>>
>>
>> Yes
>>
>>>
>>> Why it is not mixed? What are the benefits of having relayed audio
>>> channels - significant performance improvements?
>>
>>
>> Yes. Very significant. To the point that we are considering abandoning
>> mixer support in the bridge.
>
> Does jitsi-meet support any mobile clients?

We have been trying it on Chrome for Android and it's been quite
reasonable. I know some people are also using it with native clients
(which is also what we should have soon).

> How many audio streams have you
> found are reasonable to send to mobile?

I've seen things work pretty smoothly with 5 or 6 participants.

> That's an area we've seen sending a
> pre-mixed stream is beneficial.

One would think so yes. Still, our thinking so far has been that we
should rather try to avoid that even for constrained devices.

A mobile device should be able to decently decode a few audio streams
without hitting performance issues and that's the maximum that also
works from a usability perspective.

So the idea is that If you find yourself in a situation where your
mobile device is getting more than that then it would be better to try
and get out of that situation. Even if you managed to get the device
to render a mix of 15 pre-mixed streams and they are not mostly
silence then you are in trouble anyway.

Does that make sense?

Emil

>>
>>
>>>
>>> Will the dominant speaker recognition still work if the audio is
mixed?
>>
>>
>> Not sure. Give it a try.
>>
>> Emil
>>>
>>>
>>> Thanks for all your support.
>>>
>>> Regards,
>>> Mihail
>>
>>
>>
>> --
>> sent from my mobile
>>
>> _______________________________________________
>> dev mailing list
>> dev@jitsi.org
>> Unsubscribe instructions and other list options:
>> http://lists.jitsi.org/mailman/listinfo/dev
>
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

--
https://jitsi.org

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#5

Hey Brian,

A question inline

Hey Mihail,

Answers inline:

Hi,

While developing an application that uses jitsi videobridge I have
noticed that the video streams are relayed fine but the audio is not
delivered properly.

In the implementation it is assumed that the bridge by default mixes
audio (in contrast to video which is relayed). The SSRC of each bridge audio
channel is signaled to the corresponding participant but the audio SSRC-s
announced by the client are not propagated to all other participants (just
to the bridge itself). My understanding is that this would have been
sufficient if the above assumption is correct i.e. the bridge does actually
mix the audio streams. Please confirm!

However, observing the actual results I can infer that the videobridge
just relays the audio streams as it does with video.

Having this in mind could you please provide some input on the following:

1. Does the latest videobridge support audio mixing?

Yes.

If yes, is this the default behavior

No

or it should be explicitly requested - e.g. by setting
rtp-level-relay-type='mixer' attribute on the audio channel, etc.

Yes

The colibri protocol specification (https://jitsi.org/colibri/) is not
quite clear for me in this area...

2. In jitsi meet the audio is relayed. Am I correct?

Yes

Why it is not mixed? What are the benefits of having relayed audio
channels - significant performance improvements?

Yes. Very significant. To the point that we are considering abandoning
mixer support in the bridge.

Does jitsi-meet support any mobile clients?

We have been trying it on Chrome for Android and it's been quite
reasonable. I know some people are also using it with native clients
(which is also what we should have soon).

How many audio streams have you
found are reasonable to send to mobile?

I've seen things work pretty smoothly with 5 or 6 participants.

That's an area we've seen sending a
pre-mixed stream is beneficial.

One would think so yes. Still, our thinking so far has been that we
should rather try to avoid that even for constrained devices.

A mobile device should be able to decently decode a few audio streams
without hitting performance issues and that's the maximum that also
works from a usability perspective.

So the idea is that If you find yourself in a situation where your
mobile device is getting more than that then it would be better to try
and get out of that situation. Even if you managed to get the device
to render a mix of 15 pre-mixed streams and they are not mostly
silence then you are in trouble anyway.

Does that make sense?

Emil

···

On Wed, Aug 12, 2015 at 10:58 AM, Brian Baldino <brian@highfive.com> wrote:

On Wed, Aug 12, 2015 at 6:19 AM, Emil Ivov <emcho@jitsi.org> wrote:

On Wednesday, August 12, 2015, Mihail Bratoev <mbratoev@gmail.com> wrote:

Will the dominant speaker recognition still work if the audio is mixed?

Not sure. Give it a try.

Emil

Thanks for all your support.

Regards,
Mihail

--
sent from my mobile

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
https://jitsi.org


#6

Thanks Emil for the prompt response!

···

On Wed, Aug 12, 2015 at 4:19 PM, Emil Ivov <emcho@jitsi.org> wrote:

Hey Mihail,

Answers inline:

On Wednesday, August 12, 2015, Mihail Bratoev <mbratoev@gmail.com> wrote:

Hi,

While developing an application that uses jitsi videobridge I have
noticed that the video streams are relayed fine but the audio is not
delivered properly.

In the implementation it is assumed that the bridge by default mixes
audio (in contrast to video which is relayed). The SSRC of each bridge
audio channel is signaled to the corresponding participant but the audio
SSRC-s announced by the client are not propagated to all other participants
(just to the bridge itself). My understanding is that this would have been
sufficient if the above assumption is correct i.e. the bridge does actually
mix the audio streams. Please confirm!

However, observing the actual results I can infer that the videobridge
just relays the audio streams as it does with video.

Having this in mind could you please provide some input on the following:

1. Does the latest videobridge support audio mixing?

Yes.

If yes, is this the default behavior

No

or it should be explicitly requested - e.g. by setting rtp-level-relay-type='mixer'
attribute on the audio channel, etc.

Yes

The colibri protocol specification (https://jitsi.org/colibri/) is not
quite clear for me in this area...

2. In jitsi meet the audio is relayed. Am I correct?

Yes

Why it is not mixed? What are the benefits of having relayed audio
channels - significant performance improvements?

Yes. Very significant. To the point that we are considering abandoning
mixer support in the bridge.

Will the dominant speaker recognition still work if the audio is mixed?

Not sure. Give it a try.

Emil

Thanks for all your support.

Regards,
Mihail

--
sent from my mobile

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#7

Yep, makes sense. So does the bridge allow an independent last-n setting
for audio so that, even in a large conference, only a subset of audio
streams would be forwarded?

Right now we don't have any sort of audio last-n (we only do it for video).

What the bridge does is drop muted channels on reception, so ideally
you would make sure on the app layer, that as many non-active users as
possible would end up muted.

In Meet we were thinking of having a maximum-allowed-non-muted feature.

Emil

···

On Wed, Aug 12, 2015 at 2:57 PM, Brian Baldino <brian@highfive.com> wrote:

On Wed, Aug 12, 2015 at 11:32 AM, Emil Ivov <emcho@jitsi.org> wrote:

Hey Brian,

On Wed, Aug 12, 2015 at 10:58 AM, Brian Baldino <brian@highfive.com> >> wrote:
> A question inline
>
> On Wed, Aug 12, 2015 at 6:19 AM, Emil Ivov <emcho@jitsi.org> wrote:
>>
>> Hey Mihail,
>>
>> Answers inline:
>>
>> On Wednesday, August 12, 2015, Mihail Bratoev <mbratoev@gmail.com> >> >> wrote:
>>>
>>> Hi,
>>>
>>> While developing an application that uses jitsi videobridge I have
>>> noticed that the video streams are relayed fine but the audio is not
>>> delivered properly.
>>>
>>> In the implementation it is assumed that the bridge by default mixes
>>> audio (in contrast to video which is relayed). The SSRC of each bridge
>>> audio
>>> channel is signaled to the corresponding participant but the audio
>>> SSRC-s
>>> announced by the client are not propagated to all other participants
>>> (just
>>> to the bridge itself). My understanding is that this would have been
>>> sufficient if the above assumption is correct i.e. the bridge does
>>> actually
>>> mix the audio streams. Please confirm!
>>>
>>> However, observing the actual results I can infer that the videobridge
>>> just relays the audio streams as it does with video.
>>>
>>> Having this in mind could you please provide some input on the
>>> following:
>>>
>>> 1. Does the latest videobridge support audio mixing?
>>
>>
>> Yes.
>>
>>>
>>> If yes, is this the default behavior
>>
>>
>> No
>>
>>>
>>> or it should be explicitly requested - e.g. by setting
>>> rtp-level-relay-type='mixer' attribute on the audio channel, etc.
>>
>>
>> Yes
>>
>>>
>>> The colibri protocol specification (https://jitsi.org/colibri/) is not
>>> quite clear for me in this area...
>>>
>>> 2. In jitsi meet the audio is relayed. Am I correct?
>>
>>
>> Yes
>>
>>>
>>> Why it is not mixed? What are the benefits of having relayed audio
>>> channels - significant performance improvements?
>>
>>
>> Yes. Very significant. To the point that we are considering abandoning
>> mixer support in the bridge.
>
> Does jitsi-meet support any mobile clients?

We have been trying it on Chrome for Android and it's been quite
reasonable. I know some people are also using it with native clients
(which is also what we should have soon).

> How many audio streams have you
> found are reasonable to send to mobile?

I've seen things work pretty smoothly with 5 or 6 participants.

> That's an area we've seen sending a
> pre-mixed stream is beneficial.

One would think so yes. Still, our thinking so far has been that we
should rather try to avoid that even for constrained devices.

A mobile device should be able to decently decode a few audio streams
without hitting performance issues and that's the maximum that also
works from a usability perspective.

So the idea is that If you find yourself in a situation where your
mobile device is getting more than that then it would be better to try
and get out of that situation. Even if you managed to get the device
to render a mix of 15 pre-mixed streams and they are not mostly
silence then you are in trouble anyway.

Does that make sense?

Emil

>>
>>
>>>
>>> Will the dominant speaker recognition still work if the audio is
>>> mixed?
>>
>>
>> Not sure. Give it a try.
>>
>> Emil
>>>
>>>
>>> Thanks for all your support.
>>>
>>> Regards,
>>> Mihail
>>
>>
>>
>> --
>> sent from my mobile
>>
>> _______________________________________________
>> dev mailing list
>> dev@jitsi.org
>> Unsubscribe instructions and other list options:
>> http://lists.jitsi.org/mailman/listinfo/dev
>
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

--
https://jitsi.org

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
https://jitsi.org


#8

Ok cool...the "maximum-allowed-non-muted" feature sounds like it'd be
equivalent to a "last-n" on the audio channel, is that true? Or is there
something I'm missing?

···

On Wed, Aug 12, 2015 at 2:46 PM, Emil Ivov <emcho@jitsi.org> wrote:

On Wed, Aug 12, 2015 at 2:57 PM, Brian Baldino <brian@highfive.com> wrote:
> Yep, makes sense. So does the bridge allow an independent last-n setting
> for audio so that, even in a large conference, only a subset of audio
> streams would be forwarded?

Right now we don't have any sort of audio last-n (we only do it for video).

What the bridge does is drop muted channels on reception, so ideally
you would make sure on the app layer, that as many non-active users as
possible would end up muted.

In Meet we were thinking of having a maximum-allowed-non-muted feature.

Emil

>
> On Wed, Aug 12, 2015 at 11:32 AM, Emil Ivov <emcho@jitsi.org> wrote:
>>
>> Hey Brian,
>>
>> On Wed, Aug 12, 2015 at 10:58 AM, Brian Baldino <brian@highfive.com> > >> wrote:
>> > A question inline
>> >
>> > On Wed, Aug 12, 2015 at 6:19 AM, Emil Ivov <emcho@jitsi.org> wrote:
>> >>
>> >> Hey Mihail,
>> >>
>> >> Answers inline:
>> >>
>> >> On Wednesday, August 12, 2015, Mihail Bratoev <mbratoev@gmail.com> > >> >> wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> While developing an application that uses jitsi videobridge I have
>> >>> noticed that the video streams are relayed fine but the audio is not
>> >>> delivered properly.
>> >>>
>> >>> In the implementation it is assumed that the bridge by default mixes
>> >>> audio (in contrast to video which is relayed). The SSRC of each
bridge
>> >>> audio
>> >>> channel is signaled to the corresponding participant but the audio
>> >>> SSRC-s
>> >>> announced by the client are not propagated to all other participants
>> >>> (just
>> >>> to the bridge itself). My understanding is that this would have been
>> >>> sufficient if the above assumption is correct i.e. the bridge does
>> >>> actually
>> >>> mix the audio streams. Please confirm!
>> >>>
>> >>> However, observing the actual results I can infer that the
videobridge
>> >>> just relays the audio streams as it does with video.
>> >>>
>> >>> Having this in mind could you please provide some input on the
>> >>> following:
>> >>>
>> >>> 1. Does the latest videobridge support audio mixing?
>> >>
>> >>
>> >> Yes.
>> >>
>> >>>
>> >>> If yes, is this the default behavior
>> >>
>> >>
>> >> No
>> >>
>> >>>
>> >>> or it should be explicitly requested - e.g. by setting
>> >>> rtp-level-relay-type='mixer' attribute on the audio channel, etc.
>> >>
>> >>
>> >> Yes
>> >>
>> >>>
>> >>> The colibri protocol specification (https://jitsi.org/colibri/) is
not
>> >>> quite clear for me in this area...
>> >>>
>> >>> 2. In jitsi meet the audio is relayed. Am I correct?
>> >>
>> >>
>> >> Yes
>> >>
>> >>>
>> >>> Why it is not mixed? What are the benefits of having relayed audio
>> >>> channels - significant performance improvements?
>> >>
>> >>
>> >> Yes. Very significant. To the point that we are considering
abandoning
>> >> mixer support in the bridge.
>> >
>> > Does jitsi-meet support any mobile clients?
>>
>> We have been trying it on Chrome for Android and it's been quite
>> reasonable. I know some people are also using it with native clients
>> (which is also what we should have soon).
>>
>> > How many audio streams have you
>> > found are reasonable to send to mobile?
>>
>> I've seen things work pretty smoothly with 5 or 6 participants.
>>
>> > That's an area we've seen sending a
>> > pre-mixed stream is beneficial.
>>
>> One would think so yes. Still, our thinking so far has been that we
>> should rather try to avoid that even for constrained devices.
>>
>> A mobile device should be able to decently decode a few audio streams
>> without hitting performance issues and that's the maximum that also
>> works from a usability perspective.
>>
>> So the idea is that If you find yourself in a situation where your
>> mobile device is getting more than that then it would be better to try
>> and get out of that situation. Even if you managed to get the device
>> to render a mix of 15 pre-mixed streams and they are not mostly
>> silence then you are in trouble anyway.
>>
>> Does that make sense?
>>
>> Emil
>>
>>
>>
>>
>> >>
>> >>
>> >>>
>> >>> Will the dominant speaker recognition still work if the audio is
>> >>> mixed?
>> >>
>> >>
>> >> Not sure. Give it a try.
>> >>
>> >> Emil
>> >>>
>> >>>
>> >>> Thanks for all your support.
>> >>>
>> >>> Regards,
>> >>> Mihail
>> >>
>> >>
>> >>
>> >> --
>> >> sent from my mobile
>> >>
>> >> _______________________________________________
>> >> dev mailing list
>> >> dev@jitsi.org
>> >> Unsubscribe instructions and other list options:
>> >> http://lists.jitsi.org/mailman/listinfo/dev
>> >
>> >
>> >
>> > _______________________________________________
>> > dev mailing list
>> > dev@jitsi.org
>> > Unsubscribe instructions and other list options:
>> > http://lists.jitsi.org/mailman/listinfo/dev
>>
>>
>>
>> --
>> https://jitsi.org
>>
>> _______________________________________________
>> dev mailing list
>> dev@jitsi.org
>> Unsubscribe instructions and other list options:
>> http://lists.jitsi.org/mailman/listinfo/dev
>
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

--
https://jitsi.org

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#9

Yes and no.

Yes it will have the same result: at any given time you will only be
getting audio from the last N participants that have been dominant speakers
(ish).

No because:
A) it will be implemented in Meet and not in the bridge and
B) because users will enter the set if qnd only if they unmute themselves
manually. They would be booted out of the set (and visibly muted in their
gui) when enough people come in to push them down the line.

The whole idea is that you can't muck about with audio on the bridge and
drop t the same way you drop video. If a video stream appears a bit later
than it was meant to, it's no big deal. If that happens to an audio stream
you are in trouble.

Emil

···

On Wednesday, August 12, 2015, Brian Baldino <brian@highfive.com> wrote:

Ok cool...the "maximum-allowed-non-muted" feature sounds like it'd be
equivalent to a "last-n" on the audio channel, is that true? Or is there
something I'm missing?

On Wed, Aug 12, 2015 at 2:46 PM, Emil Ivov <emcho@jitsi.org > <javascript:_e(%7B%7D,'cvml','emcho@jitsi.org');>> wrote:

On Wed, Aug 12, 2015 at 2:57 PM, Brian Baldino <brian@highfive.com >> <javascript:_e(%7B%7D,'cvml','brian@highfive.com');>> wrote:
> Yep, makes sense. So does the bridge allow an independent last-n
setting
> for audio so that, even in a large conference, only a subset of audio
> streams would be forwarded?

Right now we don't have any sort of audio last-n (we only do it for
video).

What the bridge does is drop muted channels on reception, so ideally
you would make sure on the app layer, that as many non-active users as
possible would end up muted.

In Meet we were thinking of having a maximum-allowed-non-muted feature.

Emil

>
> On Wed, Aug 12, 2015 at 11:32 AM, Emil Ivov <emcho@jitsi.org >> <javascript:_e(%7B%7D,'cvml','emcho@jitsi.org');>> wrote:
>>
>> Hey Brian,
>>
>> On Wed, Aug 12, 2015 at 10:58 AM, Brian Baldino <brian@highfive.com >> <javascript:_e(%7B%7D,'cvml','brian@highfive.com');>> >> >> wrote:
>> > A question inline
>> >
>> > On Wed, Aug 12, 2015 at 6:19 AM, Emil Ivov <emcho@jitsi.org >> <javascript:_e(%7B%7D,'cvml','emcho@jitsi.org');>> wrote:
>> >>
>> >> Hey Mihail,
>> >>
>> >> Answers inline:
>> >>
>> >> On Wednesday, August 12, 2015, Mihail Bratoev <mbratoev@gmail.com >> <javascript:_e(%7B%7D,'cvml','mbratoev@gmail.com');>> >> >> >> wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> While developing an application that uses jitsi videobridge I have
>> >>> noticed that the video streams are relayed fine but the audio is
not
>> >>> delivered properly.
>> >>>
>> >>> In the implementation it is assumed that the bridge by default
mixes
>> >>> audio (in contrast to video which is relayed). The SSRC of each
bridge
>> >>> audio
>> >>> channel is signaled to the corresponding participant but the audio
>> >>> SSRC-s
>> >>> announced by the client are not propagated to all other
participants
>> >>> (just
>> >>> to the bridge itself). My understanding is that this would have
been
>> >>> sufficient if the above assumption is correct i.e. the bridge does
>> >>> actually
>> >>> mix the audio streams. Please confirm!
>> >>>
>> >>> However, observing the actual results I can infer that the
videobridge
>> >>> just relays the audio streams as it does with video.
>> >>>
>> >>> Having this in mind could you please provide some input on the
>> >>> following:
>> >>>
>> >>> 1. Does the latest videobridge support audio mixing?
>> >>
>> >>
>> >> Yes.
>> >>
>> >>>
>> >>> If yes, is this the default behavior
>> >>
>> >>
>> >> No
>> >>
>> >>>
>> >>> or it should be explicitly requested - e.g. by setting
>> >>> rtp-level-relay-type='mixer' attribute on the audio channel, etc.
>> >>
>> >>
>> >> Yes
>> >>
>> >>>
>> >>> The colibri protocol specification (https://jitsi.org/colibri/)
is not
>> >>> quite clear for me in this area...
>> >>>
>> >>> 2. In jitsi meet the audio is relayed. Am I correct?
>> >>
>> >>
>> >> Yes
>> >>
>> >>>
>> >>> Why it is not mixed? What are the benefits of having relayed audio
>> >>> channels - significant performance improvements?
>> >>
>> >>
>> >> Yes. Very significant. To the point that we are considering
abandoning
>> >> mixer support in the bridge.
>> >
>> > Does jitsi-meet support any mobile clients?
>>
>> We have been trying it on Chrome for Android and it's been quite
>> reasonable. I know some people are also using it with native clients
>> (which is also what we should have soon).
>>
>> > How many audio streams have you
>> > found are reasonable to send to mobile?
>>
>> I've seen things work pretty smoothly with 5 or 6 participants.
>>
>> > That's an area we've seen sending a
>> > pre-mixed stream is beneficial.
>>
>> One would think so yes. Still, our thinking so far has been that we
>> should rather try to avoid that even for constrained devices.
>>
>> A mobile device should be able to decently decode a few audio streams
>> without hitting performance issues and that's the maximum that also
>> works from a usability perspective.
>>
>> So the idea is that If you find yourself in a situation where your
>> mobile device is getting more than that then it would be better to try
>> and get out of that situation. Even if you managed to get the device
>> to render a mix of 15 pre-mixed streams and they are not mostly
>> silence then you are in trouble anyway.
>>
>> Does that make sense?
>>
>> Emil
>>
>>
>>
>>
>> >>
>> >>
>> >>>
>> >>> Will the dominant speaker recognition still work if the audio is
>> >>> mixed?
>> >>
>> >>
>> >> Not sure. Give it a try.
>> >>
>> >> Emil
>> >>>
>> >>>
>> >>> Thanks for all your support.
>> >>>
>> >>> Regards,
>> >>> Mihail
>> >>
>> >>
>> >>
>> >> --
>> >> sent from my mobile
>> >>
>> >> _______________________________________________
>> >> dev mailing list
>> >> dev@jitsi.org <javascript:_e(%7B%7D,'cvml','dev@jitsi.org');>
>> >> Unsubscribe instructions and other list options:
>> >> http://lists.jitsi.org/mailman/listinfo/dev
>> >
>> >
>> >
>> > _______________________________________________
>> > dev mailing list
>> > dev@jitsi.org <javascript:_e(%7B%7D,'cvml','dev@jitsi.org');>
>> > Unsubscribe instructions and other list options:
>> > http://lists.jitsi.org/mailman/listinfo/dev
>>
>>
>>
>> --
>> https://jitsi.org
>>
>> _______________________________________________
>> dev mailing list
>> dev@jitsi.org <javascript:_e(%7B%7D,'cvml','dev@jitsi.org');>
>> Unsubscribe instructions and other list options:
>> http://lists.jitsi.org/mailman/listinfo/dev
>
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org <javascript:_e(%7B%7D,'cvml','dev@jitsi.org');>
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

--
https://jitsi.org

_______________________________________________
dev mailing list
dev@jitsi.org <javascript:_e(%7B%7D,'cvml','dev@jitsi.org');>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
sent from my mobile