Streaming: audio extremely choppy for the first few minutes then get better

Using the latest Docker image stable-5390-3 on an AWS c5.xlarge server.

Near the beginning of a meeting, I have a period of about one or two minutes in which the audio is extremely bad, like cut for two second, work for a fraction of second, cut again etc. During that time the video is fine. Once that period is over, the audio get back to normal and then stay normal for the rest of the meeting.

It’s not clear what trigger that period, but often it is when talking continuously for 10s/20s then stop completely. The awful audio period start just after that.

I tried to redirect the rtmp stream to youtube, an nginx/rtmp server, or even just a ffmpeg acting as a server and get the same issue.

Nothing is standing out to me in the log log.0.txt or ffmpeg.0.txt during that period.

Does anybody had a similar issue ? Any advice how to debug it more thoroughly ?

Does this issue happen only when streaming? What about the recording…?

Same with recording. One or two minutes of awful audio near the beginning and then the audio is good again for the rest of the recording.

This afternoon I rebuilt the jibri docker image with a debian bullseye instead of buster, in order to get a more recent version of ffmpeg (4.3.2 instead of 4.1.6) but it didn’t change anything, same audio issue.

I’m now maybe suspecting the sound settings, because the documentation is quite confusing about it.

First it explain how to configure the playback interfaces:

# configure 5 capture/playback interfaces
echo "options snd-aloop enable=1,1,1,1,1 index=0,1,2,3,4" > /etc/modprobe.d/alsa-loopback.conf
# setup autoload the module
echo "snd-aloop" >> /etc/modules
# check that the module is loaded
lsmod | grep snd_aloop

This part is fine. In my case I needed a bit more so I declared:

echo “options snd-aloop enable=1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1 index=0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16”

Also the doc explains for AWS user like me how to install the generic kernel, this part is also fine.

But then the documentation state that each container need to have an .asoundrc like this (with N being the index of the container):


slave.pcm “hw:N,0,0”

slave.pcm “hw:N,0,1”

slave.pcm “hw:N,1,1”

slave.pcm “hw:N,1,0”

Which is super misleading from what I understand ? This configuration doesn’t work at all, I don’t get any sound. After many trial and errors and search on this forum, I ended up with:

...
slave.pcm "hw:N,0,0"
...
slave.pcm "hw:N+1,1,0"
...
slave.pcm "hw:N+1,0,0"
...
slave.pcm "hw:N,1,0"
...

Which seems to work (but oddly now use two interfaces by container?), but I don’t know how to confirm it’s correct. Maybe it’s the root cause of my sound issue.

If you get the audio then the loopback audio devices should be OK. They are not related with the audio quality.

How many JVB do you have? If it’s more than one, did you check the websocket?

Thanks!

It’s a test environment, so I have only one Meet(prosody/jicofo) and one JVB server so far, but I will scale to more JVB later. By the way, the JVB and jibri server are both in the same AWS region, VPC and subnet so the network speed should be ok.

Websockets are working. The dominant speaker and simulcast are ok, also I get the message “websocket channel opened” in the log.

Btw, this sound issue for one or two minutes near the beginning of a meeting happen only for recording/streaming. For the participant the sound is good during the entire meeting, that’s why I’m suspecting the jibri server.

Finally found the root cause of the issue. It was the number of virtual cards. I was declaring 16 of then in the alsa-loopback.conf:

echo “options snd-aloop enable=1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1 index=0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16”

When I decrease the amount of them, the choppy period also get shorter accordingly. With only 4 virtual cards remaining, the choppy period is less than 5 seconds, almost not noticeable.

echo “options snd-aloop enable=1,1,1,1 index=0,1,2,3”

1 Like

Does setting the pcm_substreams have any effect? Its default value is 8

options snd-aloop enable=1,1,1,... index=0,1,2,... pcm_substreams=1,1,1,...

Interesting idea, but unfortunately doesn’t have any effect. Same 1 or 2 minutes of choppy period with 16 cards and one pcm_substreams for each.

aplay -l

**** List of PLAYBACK Hardware Devices ****
card 0: Loopback [Loopback], device 0: Loopback PCM [Loopback PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Loopback [Loopback], device 1: Loopback PCM [Loopback PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: Loopback_1 [Loopback], device 0: Loopback PCM [Loopback PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: Loopback_1 [Loopback], device 1: Loopback PCM [Loopback PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 2: Loopback_2 [Loopback], device 0: Loopback PCM [Loopback PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 2: Loopback_2 [Loopback], device 1: Loopback PCM [Loopback PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 3: Loopback_3 [Loopback], device 0: Loopback PCM [Loopback PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 3: Loopback_3 [Loopback], device 1: Loopback PCM [Loopback PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 4: Loopback_4 [Loopback], device 0: Loopback PCM [Loopback PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 4: Loopback_4 [Loopback], device 1: Loopback PCM [Loopback PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 5: Loopback_5 [Loopback], device 0: Loopback PCM [Loopback PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 5: Loopback_5 [Loopback], device 1: Loopback PCM [Loopback PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 6: Loopback_6 [Loopback], device 0: Loopback PCM [Loopback PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 6: Loopback_6 [Loopback], device 1: Loopback PCM [Loopback PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 7: Loopback_7 [Loopback], device 0: Loopback PCM [Loopback PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 7: Loopback_7 [Loopback], device 1: Loopback PCM [Loopback PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 8: Loopback_8 [Loopback], device 0: Loopback PCM [Loopback PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 8: Loopback_8 [Loopback], device 1: Loopback PCM [Loopback PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 9: Loopback_9 [Loopback], device 0: Loopback PCM [Loopback PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 9: Loopback_9 [Loopback], device 1: Loopback PCM [Loopback PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 10: Loopback_A [Loopback], device 0: Loopback PCM [Loopback PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 10: Loopback_A [Loopback], device 1: Loopback PCM [Loopback PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 11: Loopback_B [Loopback], device 0: Loopback PCM [Loopback PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 11: Loopback_B [Loopback], device 1: Loopback PCM [Loopback PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 12: Loopback_C [Loopback], device 0: Loopback PCM [Loopback PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 12: Loopback_C [Loopback], device 1: Loopback PCM [Loopback PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 13: Loopback_D [Loopback], device 0: Loopback PCM [Loopback PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 13: Loopback_D [Loopback], device 1: Loopback PCM [Loopback PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 14: Loopback_E [Loopback], device 0: Loopback PCM [Loopback PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 14: Loopback_E [Loopback], device 1: Loopback PCM [Loopback PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0