You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
Any idea?
Thanks
/Kaiduan
The text was updated successfully, but these errors were encountered: