[jitsi-users] Issues with Jibri and pjsua


#1

Hi all,

A while ago I saw a demonstration of Jitsi using Jibri for connecting a videoroom to a Jitsi videoconference: https://www.youtube.com/watch?v=TGloLKOrvmo&t=1306s. I would love to reproduce this result, but I am having trouble getting pjsua to work correctly.

I managed to get Jibri to stream to YouTube, so I know Jibri is working correctly. Running pjsua is a different story. Unfortunately there is no documentation on which configuration is needed for pjsua or how to start pjsua from Jibri. I noticed a flag in in app.py and jibriselenium.py and I set those pjsua flags to true. This results in Jibri starting pjsua when clicking on stream to YouTube in the Jitsi Meet web interface. I hardcoded my videoroom sip address in start_pjsua.sh, which works fine for testing.

I downloaded pjproject 2.7.1. and compiled it using './configure --disable-speex-aec --disable-speex-codec' (because speex is not supported on the voip platform I am using). The default start-pjsua.sh file in the git repo of Jibri defines device ids 23 and 24 for capture and playback. These ids seem to be specific for the system it was used on. Based on the configuration of the loopback devices it seems that pjsua should be using cloop for capture and ploop for playback. These devices have a specific id and I wrote a python script that searches for the id making use of sndinfo of pjsua (recompiled pjproject using: 'svn cat http://svn.pjsip.org/repos/pjproject/trunk/pjsip-apps/src/samples/sndinfo.c@r2401 > pjsip-apps/src/samples/sndinfo.c'). I now can see in the logging that pjsua is using cloop and ploop for capture and playback. And here is where the trouble starts. Everytime I try to start pjsua with cloop and ploop, pjsua crashes with a segfault (139). It is not clear to me why. I tried loads of startup options, but no luck so far. The only way I can get pjsua to start without crashing is by starting pjsua using ploop for capture and playback. But this leads to a situation where only the audio captured in the videoroom can be heared in the Jitsi videoconference and the videoroom does not receive any audio (which is understandable because Jibri is playing sound on amix which is looped back to cloop).

I am now testing pjsua manually by playing a wav file to the loopback device. The only way pjsua is not crashing is by playing the wav to ploop and using asnoop as capture device for pjsua. But the sample rate of the wav file somehow has to be 8kHz because any higher will result into a crash of pjsua. But with this set up the audio is very (very!) choppy and pjsua is logging this:

10:57:08.038 alsa_dev.c !ca_thread_func: overrun!
10:57:08.038 strm0x7f63a40088a8 !Jitter buffer starts returning normal frames (after 13 empty/lost)
10:57:08.038 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.038 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.038 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.038 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.038 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.039 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.039 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.039 strm0x7f63a40088a8 Jitter buffer empty (prefetch=0), plc invoked
10:57:08.039 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.039 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.039 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.039 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.039 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.040 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.040 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.040 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.040 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.040 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.040 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.162 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.162 strm0x7f63a40088a8 Jitter buffer starts returning normal frames (after 12 empty/lost)
10:57:08.162 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.162 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.162 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.162 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.162 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.162 strm0x7f63a40088a8 Jitter buffer empty (prefetch=0), plc invoked

The audio can be heared perfectly when I play the original wav file (44.1 kHz) directly by starting pjsua with '--play-file audio.wav --auto-play'.

Is there a configuration setting I am missing for getting cloop to work without crashing pjsua? I have not yet looked in to the video part because of the problems I am having with the audio. So currently no audio is being streamed from or to the videoroom with my current set up.

Kind regards,

Erwin


#2

I managed to fix my issue by changing the capture-dev id for pjsua. Somehow pjsua does not want to use cloop as capture device which is on (Loopback) device 1 in my case. When using plughw:CARD=Loopback,DEV=1 as capture device for pjsua (id = 21 in my case) the problem somehow is solved. I don't know why or how, but maybe this will help someone in the future.

I wrote the following python script for finding the correct device id based on the device name. Sometimes the device id changes because another device is in use.

import sys
import subprocess
import os
import getopt

def find_by_args(argv):
    try:
opts, args = getopt.getopt(argv, "hd:", ["device="])
    except getopt.GetoptError:
print('testing.py -d <device_name>')
sys.exit(2)
    for opt, arg in opts:
if opt == '-h':
    print('testing.py -d <device_name>')
    sys.exit()
elif opt in ("-d", "--device"):
    return find_id_where_device_name_is(arg)

def find_id_where_device_name_is(device_name):
    FNULL = open(os.devnull, 'w')
    result = subprocess.Popen(['./sndinfo'], stdout=subprocess.PIPE, stderr=FNULL)
    lines = result.stdout.readlines()
    indices = [i for i, s in enumerate(lines) if str(device_name) in str(s)]

    for index in indices:
if index == 0:
    continue
if '#' in str(lines[index-1]):
    id = str(lines[index-1]).split('#', 1)[-1].split(':', 1)[0]
    return(id)

if __name__ == '__main__':
    device_id = str(find_by_args(sys.argv[1:]))

    sys.stdout.write(device_id)

This script uses sndinfo. Execute "svn cat http://svn.pjsip.org/repos/pjproject/trunk/pjsip-apps/src/samples/sndinfo.c@r2401 > pjsip-apps/src/samples/sndinfo.c" in the pjproject directory and add "sndinfo" to "Samples" in "pjsip-apps/build/Samples.mak". Then recompile pjproject and the sndinfo binary is located in /pjsip-apps/bin/samples/x86_64-unknown-linux-gnu/

···

________________________________
Van: users <users-bounces@jitsi.org> namens Erwin Lenting <erwinlenting@outlook.com>
Verzonden: woensdag 6 december 2017 11:08:47
Aan: users@jitsi.org
Onderwerp: [jitsi-users] Issues with Jibri and pjsua

Hi all,

A while ago I saw a demonstration of Jitsi using Jibri for connecting a videoroom to a Jitsi videoconference: https://www.youtube.com/watch?v=TGloLKOrvmo&t=1306s. I would love to reproduce this result, but I am having trouble getting pjsua to work correctly.

I managed to get Jibri to stream to YouTube, so I know Jibri is working correctly. Running pjsua is a different story. Unfortunately there is no documentation on which configuration is needed for pjsua or how to start pjsua from Jibri. I noticed a flag in in app.py and jibriselenium.py and I set those pjsua flags to true. This results in Jibri starting pjsua when clicking on stream to YouTube in the Jitsi Meet web interface. I hardcoded my videoroom sip address in start_pjsua.sh, which works fine for testing.

I downloaded pjproject 2.7.1. and compiled it using './configure --disable-speex-aec --disable-speex-codec' (because speex is not supported on the voip platform I am using). The default start-pjsua.sh file in the git repo of Jibri defines device ids 23 and 24 for capture and playback. These ids seem to be specific for the system it was used on. Based on the configuration of the loopback devices it seems that pjsua should be using cloop for capture and ploop for playback. These devices have a specific id and I wrote a python script that searches for the id making use of sndinfo of pjsua (recompiled pjproject using: 'svn cat http://svn.pjsip.org/repos/pjproject/trunk/pjsip-apps/src/samples/sndinfo.c@r2401 > pjsip-apps/src/samples/sndinfo.c'). I now can see in the logging that pjsua is using cloop and ploop for capture and playback. And here is where the trouble starts. Everytime I try to start pjsua with cloop and ploop, pjsua crashes with a segfault (139). It is not clear to me why. I tried loads of startup options, but no luck so far. The only way I can get pjsua to start without crashing is by starting pjsua using ploop for capture and playback. But this leads to a situation where only the audio captured in the videoroom can be heared in the Jitsi videoconference and the videoroom does not receive any audio (which is understandable because Jibri is playing sound on amix which is looped back to cloop).

I am now testing pjsua manually by playing a wav file to the loopback device. The only way pjsua is not crashing is by playing the wav to ploop and using asnoop as capture device for pjsua. But the sample rate of the wav file somehow has to be 8kHz because any higher will result into a crash of pjsua. But with this set up the audio is very (very!) choppy and pjsua is logging this:

10:57:08.038 alsa_dev.c !ca_thread_func: overrun!
10:57:08.038 strm0x7f63a40088a8 !Jitter buffer starts returning normal frames (after 13 empty/lost)
10:57:08.038 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.038 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.038 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.038 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.038 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.039 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.039 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.039 strm0x7f63a40088a8 Jitter buffer empty (prefetch=0), plc invoked
10:57:08.039 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.039 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.039 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.039 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.039 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.040 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.040 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.040 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.040 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.040 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.040 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.162 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.162 strm0x7f63a40088a8 Jitter buffer starts returning normal frames (after 12 empty/lost)
10:57:08.162 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.162 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.162 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.162 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.162 Master/sound Underflow, buf_cnt=0, will generate 1 frame
10:57:08.162 strm0x7f63a40088a8 Jitter buffer empty (prefetch=0), plc invoked

The audio can be heared perfectly when I play the original wav file (44.1 kHz) directly by starting pjsua with '--play-file audio.wav --auto-play'.

Is there a configuration setting I am missing for getting cloop to work without crashing pjsua? I have not yet looked in to the video part because of the problems I am having with the audio. So currently no audio is being streamed from or to the videoroom with my current set up.

Kind regards,

Erwin