I have a successful early prototype of Jamulus Client working as an audio plugin.
This has no relevance to the Jamulus server, which is compatible without modification.
But I have in the process seen that for transmitting audio, several things happen in the audio callback method “CSoundBase::ProcessCallback”, which are very likely to cause audio artefacts/dropouts:
1: In CChannel::PrepAndSendPacket, there is a QMutexLocker. Locking is really to be avoided in the audio callback.
2: pSocket->SendPacket is invoked synchronously to send the packet. It should definitely instead be sending in its own thread, with a lock-free fifo buffer to feed the sending thread packets.
3: Then, in SendPacket there is also memory allocation, and further locking, but I guess by addressing 2 these are fine.
4: With CChannel::bDoAutoSockBufSize set to true, there’s further locking and possible allocation, which I guess is most simply resolved by keeping it as false.
Those are the ones I’ve identified till now.
My plan is to make Jamulus start another thread, just like the receiving one, also for sending.
Do you know, has anyone made anything similar that I can look at or will I be the first?
If you are aware of any fork/branch, or have any other tips on this, I’d love to know!
Thank you.
👍
3
Last edit: onar3d 2021-01-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi!
I have a successful early prototype of Jamulus Client working as an audio plugin.
This has no relevance to the Jamulus server, which is compatible without modification.
But I have in the process seen that for transmitting audio, several things happen in the audio callback method “CSoundBase::ProcessCallback”, which are very likely to cause audio artefacts/dropouts:
1: In CChannel::PrepAndSendPacket, there is a QMutexLocker. Locking is really to be avoided in the audio callback.
2: pSocket->SendPacket is invoked synchronously to send the packet. It should definitely instead be sending in its own thread, with a lock-free fifo buffer to feed the sending thread packets.
3: Then, in SendPacket there is also memory allocation, and further locking, but I guess by addressing 2 these are fine.
4: With CChannel::bDoAutoSockBufSize set to true, there’s further locking and possible allocation, which I guess is most simply resolved by keeping it as false.
Those are the ones I’ve identified till now.
My plan is to make Jamulus start another thread, just like the receiving one, also for sending.
Do you know, has anyone made anything similar that I can look at or will I be the first?
If you are aware of any fork/branch, or have any other tips on this, I’d love to know!
Thank you.
Last edit: onar3d 2021-01-21