sipp icon indicating copy to clipboard operation
sipp copied to clipboard

audio is distorted with rtp_stream for load test

Open kaiduanx opened this issue 2 years ago • 2 comments

  1. rtp_stream a wav file with min_rtp_port, max_rtp_port
  2. sipp 3.7.1
  3. With one call test (-m 1), the receiver side got the same audio as the original wav file without loss/distortion
  4. With load test -r 3 -m 9, the audio from the receiver side got distorted (play the audio from wireshark pcap)

Any idea?

Thanks

/Kaiduan

kaiduanx avatar Oct 20 '23 14:10 kaiduanx

In rtpstream.cpp, in rtpstream_playrtptask(),

A packet is sent and then a packet is received after select() on the rtp socket. The select() uses the variable tv set up at the top of the function as the timeout to block for.

[https://github.com/SIPp/sipp/blob/060c576a139a124300ee026ec4c9bd153c321c78/src/rtpstream.cpp#L655]

tv.tv_usec is set to 10000, causing the select() to block for up to 10ms on the packet receive. Default ptime is only 20ms per packet, so if this starts waiting, the loop calling rtpstream_playrtptask for each task in the thread for each wakeup time will fall hopelessly behind in processing.

Set that tv.tv_usec to 0 so that the select will return immediately if no packet is available, and your audio stream will run more smoothly.

acumeeple avatar Jan 29 '24 15:01 acumeeple

Also, the uasAudioMutex / uasVideoMutex / uacAudioMutex / uacVideoMutex appear to be being locked and unlocked even if USE_SSL is not defined, even though the appear to exist only to protect the global JLSRTP contexts.

This will cause multiple rtpstream threads to serialise their activity unnecessarily.

Further testing seems to show that these mutexes are harmless at my own testing loads. YMMV.

acumeeple avatar Jan 29 '24 15:01 acumeeple