I am using jitsi videobridge with webrtc
the webpage says that audio mixing is "supported"
Can you please clarify if this (audio mixing)
or if it somehow needs to be enabled?
Mixing is not the default, it needs to be enabled
can do that by adding rtp-level-relay-type='mixer'
elements in COLIBRI. See XEP-0340.
Thanks Boris. I'm a little unclear where this fits in
picture I am using jicofo which as I understand to be
the COLIBRI interactions. do I need to add this to jicofo
is there maybe a configuration parameter?
Jicofo doesn't support it, but it should be easy to add (see
Thanks Boris. I think I have figured out the relevant chanegs
to try this out. I will try it tomorrow.
While I am on the subject: would you be able to please clarify
what the default behavior is of jitsi-videobridge in terms of audio
stream bandwidth usage. does relayed audio simply mean that
is getting N individual streams realyed to them from the bridge?
so if (for example) I had a conference with 8 users each using
50kbit of audio bandwidth then would that result in each client
requirement of approx 400kbit of bandwidth usage to participate
conference? or is it not that simple?
Yes that's it (except that the bridge may drop some silence packets,
but I don't think this is significant). Compared to the bandwidth
requirements for video, audio is cheap, so it hasn't seen much work.
that would be my expectation too but I'm seeing quite bad lag / crackle
with > 4 users to the point where it doesn't seem usable. I'm not
entirely sure where to start diagnosising the problem. i.e. users can
make statements like "it is laggy and crackly" but it is hard to turn
that into a diagnosis or pointer to where the problem may lie i.e.
could it be the server, the network bandwidth, webrtc library, the
Android device etc. or some combination of those.
I would have thought that if I were to limit the per-user audio bitrate
to (say) 20 kbit then even worst case that is 200kbit for 10 users which
still doesn't seem in any way an unreasonable bandwidth expectation.
would you agree?
so maybe it isn't bandwidth at all? maybe it is somehow CPU based with
remixing the streams (on the Android devices)? if that is the case then
mixing should help. but it wasnt noticeably better unless maybe I have
configured it incorrectly.
can you suggest any other factors or areas of investigation I can dig
into to try to get a better handle on this? Does jitsi itself have any
metrics or diagnostics that would be helpful here? I was thinking I can
rule out bandwidth from the picture entirely by running the entire
system on a LAN. I will try that next. if I still have problems I know
I can look somewhere else other than bandwidth.
The chrome://webrtc-internals page should help you with debugging, although it may not be easy to use on android. You can start by looking for packet loss on the audio stream(s).
Currently I am using the OPUS codec. would you recommend any other
codecs/settings worth trying? particularly for mobile users.
I wouldn't know, really. I suppose you can try (since you're recompiling jicofo already this will be easy, just remove opus from JingleOfferFactory.java) so you can to rule out any opus-specific bugs. Modern android devices should be powerful enough to handle a couple of opus streams, so if the problem is not enough cycles for audio decoding, I would suspect the cause is somewhere else.
On 22/04/16 15:02, Raoul Duke wrote:
On Fri, Apr 22, 2016 at 3:15 AM, Boris Grozev <firstname.lastname@example.org > <mailto:email@example.com>> wrote:
On 21/04/16 19:46, Raoul Duke wrote:
On Thu, Apr 21, 2016 at 3:57 PM, Boris Grozev <firstname.lastname@example.org > <mailto:email@example.com> > <mailto:firstname.lastname@example.org <mailto:email@example.com>>> wrote:
On 21/04/16 09:23, Raoul Duke wrote:
On Thu, Apr 21, 2016 at 10:00 AM, Boris Grozev > <firstname.lastname@example.org <mailto:email@example.com> > <mailto:firstname.lastname@example.org <mailto:email@example.com>> > <mailto:firstname.lastname@example.org <mailto:email@example.com> > <mailto:firstname.lastname@example.org <mailto:email@example.com>>>> wrote:
On 20/04/16 17:14, Raoul Duke wrote: