[jitsi-dev] [jitsi/jitsi-videobridge] jvb doesn't forward all audio (#198)


#1

We're running into some problems where the bridge does not forward all audio. We've also seen that someone can talk for a long time (with others muted) and not have their video forwarded (this is all using last-n); unclear whether or not these are the same problem.

We can repro this every time, the scenario has been:
1) Totally stalk jvb
2) Bridge config has:

org.jitsi.videobridge.rest.jetty.port=8090
org.jitsi.videobridge.ENABLE_STATISTICS=true
org.jitsi.videobridge.rtcp.strategy=org.jitsi.impl.neomedia.rtcp.termination.strategies.BasicRTCPTerminationStrategy

3) Clients will use last-n of "2".
4) Have three clients join. All clients hear all other client's audio/see other client's video
5) Have a fourth client join. None (or at least some) will not be able to hear the 4th client. Client is sending audio and video to the bridge.

Attached logs on level FINE from an instance when it happens. I know you guys don't use last-n much, but audio shouldn't be affected by that I'd think? If you have ideas I can try on my side let me know.

NOTE: I haven't bisected this yet, but we had never seen this before recently.

[jvb.txt](https://github.com/jitsi/jitsi-videobridge/files/198670/jvb.txt)

···

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/issues/198


#2

Some more observations on this:
1) It does appear to be related to last-n. If I change last-n from "2" to "1", I can repro the problem with 3 endpoints instead of 4
2) Attached some screenshots that show some of the odd behavior: A is receiver audio data from B, but not registering any "sound" (as noted by comparing the audioInputLevel and audioOutputLevel in both pictures).
![audio_sender](https://cloud.githubusercontent.com/assets/5933991/14218932/2acdffb2-f80c-11e5-9118-63d406ef72f2.png)
![audio_receiver](https://cloud.githubusercontent.com/assets/5933991/14218933/2ace9102-f80c-11e5-9663-4026810c14e6.png)

···

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/issues/198#issuecomment-204553262


#3

Ok, think I found what's going on here. Funnily enough, this is caused by a fix we contributed :slight_smile: In the change here https://github.com/jitsi/jitsi-videobridge/pull/168/files we made the conferenceSpeechActivityEndpoints comparison order agnostic, but this is wrong. The order of those active endpoints could change in a way that affects last-n, so it needs to be treated as a change. The pinned endpoints comparison change (to compare it in an order-agnostic way) is, I think, still valid though. We should change

`if (equalAsSets(conferenceSpeechActivityEndpoints, endpointIds))`

back to

`if (conferenceSpeechActivityEndpoints.equals(endpointIds))`

in speechActivityEndpointIdsChanged. Will attach a PR.

@bgrozev

···

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/issues/198#issuecomment-205420109


#4

@bgrozev also, I wanted to ask, I was surprised to see audio affected by this problem. Does audio forwarding obey last-n? I thought that last-n settings on audio channels were ignored.

···

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/issues/198#issuecomment-205421627


#5

PR: https://github.com/jitsi/jitsi-videobridge/pull/204

···

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/issues/198#issuecomment-205441654


#6

@brianh5 thank you for the fix and apologies for the long wait.

Last-n is only taken into consideration when routing video packets. Could it be a client side issue, or do you observe a lack of packets on the network? The only other thing that I can think of is that the bridge was configured the bridge via COLIBRI/REST with the audio payload type given to the video channel (which would cause audio packets to be routed through the video channel, but should otherwise work).

···

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/issues/198#issuecomment-214494919


#7

@bgrozev i don't think it was a client-side thing, but unfortunately i'm too far removed from this issue at this point to remember more details. plus, we've now moved to audio mixing on the bridge. either way, we can ignore the audio aspect of this i think.

···

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/issues/198#issuecomment-214501554


#8

Well, if audio mixing works for you then audio packets must be passing through the correct place :slight_smile:
Still, if you want to send me some logs that contain COLIBRI signalling I can check for the channel problem.

···

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/issues/198#issuecomment-214502614


#9

Closed #198.

···

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/issues/198#event-673658868


#10

think this should be resolved now. i know we haven't seen it recently.

···

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/issues/198#issuecomment-221977471