[jitsi-users] Jitsi Videobridge - no audio is received by clients


#1

Hi,

I'm experimenting with jitsi-videobridge, but created my own custom WebRtc clients.

Video-relaying works without any problems.

But there are some strange problems with audio mixing. Basically, my WebRTC clients send audio, but do not receive any audio for some reason. In chrome://webrtc-internals I can see that audio is sent to the proper port of jitsi-videobridge, but I never get anything back. I always see for each mixed audio channel: "bytesReceived 998".
I suspect that videobridge does not send any mixed audio at all. Or may be it sends it to the wrong port. It should be something pretty simple, but I cannot figure out what it is.

In the logs of Jitsi Videobridge I typically see something like:

INFORMATION: rtpstat:Received a sender report for audio stream SSRC:436321423 [packet count:98294, bytes:7690541 ]
Mai 23, 2014 10:29:08 AM org.jitsi.util.Logger info
INFORMATION: rtpstat:Sending a report for video stream SSRC:2992193451 [packet count:306968, bytes:324482564, interarrival jitter:426, lost packets:0, time since previous report:40ms ]
Mai 23, 2014 10:29:08 AM org.jitsi.util.Logger info
INFORMATION: rtpstat:Sending a report for video stream SSRC:3216918574 [packet count:460461, bytes:486396967, interarrival jitter:474, lost packets:0, time since previous report:25ms ]
Mai 23, 2014 10:29:09 AM org.jitsi.util.Logger info
INFORMATION: rtpstat:Sending a report for video stream SSRC:2992193451 [packet count:307066, bytes:324587041, interarrival jitter:395, lost packets:0, time since previous report:65ms ]

Could you give me a few hints how I can debug this problem? May be I can enable more debug output for audio? Is it possible to see the progress/status of the audio mixer? Can I see somewhere which ports it really uses/targets when it sends audio packets? May be I should look for something specific using wireshark?

Or may be this problem is well-known and has some typical reasons I should look for?

Any help is appreciated!

Thanks,
Leo


#2

Problem solved! I slightly modified the startup Shell-scripts of my jitsi-videobridge build and copy&pasted a few things into all such scripts for all platforms. This resulted in wrong paths to native libs and thus opus and other codecs could not be found and used :frowning:

Now I fixed this issue and everything works fine. Both audio and video are streamed by the videobridge.

Thanks,
Leo


#3

Hello,

···

On 23/05/14 10:48, Leo Romanoff wrote:

Hi,

I'm experimenting with jitsi-videobridge, but created my own custom
WebRtc clients.

Video-relaying works without any problems.

But there are some strange problems with audio mixing. Basically, my
WebRTC clients send audio, but do not receive any audio for some reason.
In chrome://webrtc-internals I can see that audio is sent to the proper
port of jitsi-videobridge, but I never get anything back. I always see
for each mixed audio channel: "bytesReceived 998".
I suspect that videobridge does not send any mixed audio at all. Or may
be it sends it to the wrong port. It should be something pretty simple,
but I cannot figure out what it is.

In the logs of Jitsi Videobridge I typically see something like:

INFORMATION: rtpstat:Received a sender report for audio stream
SSRC:436321423 [packet count:98294, bytes:7690541 ]
Mai 23, 2014 10:29:08 AM org.jitsi.util.Logger info
INFORMATION: rtpstat:Sending a report for video stream SSRC:2992193451
[packet count:306968, bytes:324482564, interarrival jitter:426, lost
packets:0, time since previous report:40ms ]
Mai 23, 2014 10:29:08 AM org.jitsi.util.Logger info
INFORMATION: rtpstat:Sending a report for video stream SSRC:3216918574
[packet count:460461, bytes:486396967, interarrival jitter:474, lost
packets:0, time since previous report:25ms ]
Mai 23, 2014 10:29:09 AM org.jitsi.util.Logger info
INFORMATION: rtpstat:Sending a report for video stream SSRC:2992193451
[packet count:307066, bytes:324587041, interarrival jitter:395, lost
packets:0, time since previous report:65ms ]

Could you give me a few hints how I can debug this problem? May be I can
enable more debug output for audio? Is it possible to see the
progress/status of the audio mixer? Can I see somewhere which ports it
really uses/targets when it sends audio packets? May be I should look
for something specific using wireshark?

Recent versions of the bridge (since build 89, I believe) do not mix
audio and just relay it.

You can confirm or refute your suspicion that the bridge does not send
audio by looking for RTP packets on the ports used for audio with wireshark.

Regards,
Boris


#4

Recent versions of the bridge (since build 89, I believe) do not mix
audio and just relay it.

Oh, very interesting! What is the reason behind this decision? What are the plans when it comes to audio? Does it mean that now there are two incoming RTP streams per participant, namely audio and video? How one is supposed to mix audio now, if at all? On the client side? Or is there any option to tell the bridge that it should mix audio as it did before?

You can confirm or refute your suspicion that the bridge does not send
audio by looking for RTP packets on the ports used for audio with wireshark.

OK.

Regards,
Leo


#5

Hello,

Recent versions of the bridge (since build 89, I believe) do not mix
audio and just relay it.

Oh, very interesting! What is the reason behind this decision?

Emil will have to answer this, but one reason is efficiency -- this way
it doesn't need to decode N streams, and create and encode N different
mixes (in a conference of N).

What are
the plans when it comes to audio? Does it mean that now there are two
incoming RTP streams per participant, namely audio and video?

Yes, but that has always been the case. It's just that the RTP stream
for audio now contains multiple SSRCs, and not just one (mixed).

How one is
supposed to mix audio now, if at all? On the client side? Or is there
any option to tell the bridge that it should mix audio as it did before?

I _think_ you can enable mixing by setting the following attribute when
creating channels:
rtp-level-relay-type='mixer'

But I am not quite sure.

Regards,
Boris

···

On 23/05/14 11:32, Leo Romanoff wrote:


#6

Hello,

  Recent versions of the bridge (since build 89, I believe) do not mix
audio and just relay it.

Oh, very interesting! What is the reason behind this decision?

Emil will have to answer this, but one reason is efficiency -- this way
it doesn't need to decode N streams, and create and encode N different
mixes (in a conference of N).

That's the only reason :slight_smile:

What are
the plans when it comes to audio? Does it mean that now there are two
incoming RTP streams per participant, namely audio and video?

Yes, but that has always been the case. It's just that the RTP stream
for audio now contains multiple SSRCs, and not just one (mixed).

How one is
supposed to mix audio now, if at all? On the client side? Or is there
any option to tell the bridge that it should mix audio as it did before?

I _think_ you can enable mixing by setting the following attribute when
creating channels:
rtp-level-relay-type='mixer'

I concur.

Emil

···

On 23.05.14, 12:01, Boris Grozev wrote:

On 23/05/14 11:32, Leo Romanoff wrote:

But I am not quite sure.

--
https://jitsi.org