The current Jamulus minimum block size is 128 samples. If that is reduced to 64, the overall latency can be lowered. With 64, we have a bit higher CPU load and network load but this should be fine.
I am now starting the work on making the 64 samples block size usable. I.e. fix all the places which depend on the 128 samples setting.
Unfortunately, the new Jamulus 64 version will be incompatible with the existing Jamulus Client/Server software. My plan is to define a new IP port number for the new version. I will keep you updated on my progress and findings here in this thread.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Please report back here if you like the new version and how it performs.
In case you like to add your own 64 samples frame size Jamulus server to the server list (right now only the Central Server is present), you can do this. If you compile the server with 64 samples, it automatically changes the port number so you can use the same command line as before to register your server.
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks Volker! For 3.4.5git - is the port still 22124? I ask because we have 3.4.5git and 22124 through router as before. I can connect from laptop on my LAN but remote guys aren't connecting through same router configuration (i.e., UDP 22124 forwarded to server) as before. Should I do something else?
Last edit: Schema Man 2020-03-29
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As the 64 samples frame size Jamulus version is incompatible with the official 128 samples frame size Jamulus version, I have chosen a different port number of the 64 samples frame size version:
22064
You have to consider that port number in your router.
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Volker
Let me add my voice to the many thanking you for this software - it is a real gift to me and my bandmates.
I run Jamulus on Win10 using a Presonus audioBox 96. I tried out v3.4.5git, running the server and client on the same machine (127.0.0.1) . The good news is that the total delay dropped from 24ms to 13ms. However I found that there were many more dropouts, audible and shown as red flashes on the buffer led. I compared 3.4.4 to 3.4.5git with both set to 128 samples (double checked my ASIO panel) ; both reported a delay of 24ms but 3.4.5git had more dropouts. Even setting realtime priority and manually raising both jitter buffers on 3.4.5git yielded dropouts.
Let me know if there's anything I can do to help figure this out, even if I don't get a full 9ms reduction in latency any bit would help :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for your feedback. Yes, I also noticed that I get more drop outs than with the 128 samples version. My bandmate even told me that he does not like the sound of the new version. He says that it is not as crisp as the 128 samples version (some high frequencies are missing).
So there are some things which have to be sorted out in that 64 samples version...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Volker,
I did some FFT and frequency-response comparison between Jamulus128 and Jamulus64, all on your Central Server, both with buffer settings at 6 and High Quality Stereo Audio.
There is no difference in the Frequency-Response!
But as you see in the FFT, THD+N is much higher in the 64 Version.
I don´t know why exactly.
Regards
Manuel Skorupka
Wow, that is great. Thank you for the plots. Are you able to compile Jamulus? If yes, you could try out other OPUS quality settings and see if you can reach the THD+N of the 128 samples version.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That is bad news. So it seems the OPUS audio quality reaches a natural bound at the very low frame size of 64 samples. So it seems to be a trade-off between audio quality and latency.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There is one more thing you could try. In this line: https://github.com/corrados/jamulus/blob/master/src/global.h#L133
you can replace it by #undef USE_LOW_COMPLEXITY_CELT_ENC. That increases the computational complexity of the encoder and therefore maybe we get a better audio quality.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I´ve made some new additional measurements with the hints you gave me.
'#undef USE_LOW_COMPLEXITY_CELT_ENC improves the audio quality.
In this mode the increase of 72 coded bytes improves audio quality too, to the point of 88. It seems that it brings down the noise a little bit.
Hi Volker again,
I also did an audio comparison between Jamulus 128 with high quality audio settings and Jamulus64 compiled with '#undef USE_LOW_COMPLEXITY_CELT_ENC on different settings. It´s all stored in a reaper project. I can´t hear a difference between the different versions of Jamulus. ;)
That's good news. So with help of this setting we can get the same quality for 64 as for 128 samples frame size. Have you checked the CPU load during your tests when you changed the USE_LOW_COMPLEXITY_CELT_ENC flag? Is it significant?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On the server i checked the Jamulus CPU load with htop.
On the clients (Raspberry Pi 4, Raspberry Pi 3B) i checked the CPU load with htop.
An my client on Win10 has 2,7% cpu load.
I can´t see any big differences beween the different Jamulus versions.
But i´dont know if that is an meaningful testing methode.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This test is good enough. Ok, so I conclude that for 128 everything is fine as it is and for 64 we need to set "#undef USE_LOW_COMPLEXITY_CELT_ENC".
You have done a lot of quality tests recently. If we use 64 with "#undef USE_LOW_COMPLEXITY_CELT_ENC", do you think the number of coded bits of 72 is a good number? Or do you recommend to increase that number.
The problem is that with 72, I am already close to the maximum upload rate of my internet connection. So I still have a slight headroom but the number should be as low as possible.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I´ve also measured the data throughput with different numbers of coded bits for up- and downstream:
35 --> 464 KBit/s
72 --> 680 KBit/s
87 --> 784 KBit/s
I think that 72 is good enough. But for me I made a Jamulus Version with 35, 72 and 87 number of coded bytes. Because I will never use the low quality mode.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The dropouts are caused by your computer not having enough CPU to sample at a high rate with a small block size. If you have a new iMac Pro with 16 cores you shouldn't have any drop outs. I have a 6 core i7 and do not get drop outs when I set audio quality on medium/low. Also make sure nothing else is running on your computer taking cpu slices as that will cause less timeslicing to jamulus and thus dropouts.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Simon
I think your suggestion is reasonable, but Task Manager indicated my CPU usage was only~20%. I did notice that the "System Interrupts" process was often highest on the list of processes sorted by CPU. I have turned off every "optional" program in my start up menu and set Jamulus to "Realtime" so it may just be too much for my machine.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hey, is there a compiled mac binary of 64 to test?
A friend and I are hoping to use it for a session tomorrow, and while I run windows he only has access to mac.
Unfortunately, I don't have access to one to compile it with xcode, and he doesn't have the time to go through all of the steps to compile it.
Thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am referring to the thread: https://sourceforge.net/p/llcon/discussion/533517/thread/b779e0329c/.
The current Jamulus minimum block size is 128 samples. If that is reduced to 64, the overall latency can be lowered. With 64, we have a bit higher CPU load and network load but this should be fine.
I am now starting the work on making the 64 samples block size usable. I.e. fix all the places which depend on the 128 samples setting.
Unfortunately, the new Jamulus 64 version will be incompatible with the existing Jamulus Client/Server software. My plan is to define a new IP port number for the new version. I will keep you updated on my progress and findings here in this thread.
Ok, I think I am done with the implementation. I have now setup and run a 64 samples frame size server instance on my server. If you like you can give it a try. I have uploaded a Windows installer here: http://llcon.sourceforge.net/Jamulus-64-installer.exe
Please note that this is experimental software! Also note that the new Jamulus 64 is no longer compatible to the current Jamulus servers. If you want to connect the current Jamulus servers, you have to install the official Jamulus version from Sourceforge (3.4.4).
If you are on Linux:
- git clone https://github.com/corrados/jamulus.git
- Change this line: https://github.com/corrados/jamulus/blob/master/src/global.h#L101 to 64
- compile and run (see here: https://github.com/corrados/jamulus/blob/master/INSTALL.md for compile instructions)
Please report back here if you like the new version and how it performs.
In case you like to add your own 64 samples frame size Jamulus server to the server list (right now only the Central Server is present), you can do this. If you compile the server with 64 samples, it automatically changes the port number so you can use the same command line as before to register your server.
Thanks Volker! For 3.4.5git - is the port still 22124? I ask because we have 3.4.5git and 22124 through router as before. I can connect from laptop on my LAN but remote guys aren't connecting through same router configuration (i.e., UDP 22124 forwarded to server) as before. Should I do something else?
Last edit: Schema Man 2020-03-29
As the 64 samples frame size Jamulus version is incompatible with the official 128 samples frame size Jamulus version, I have chosen a different port number of the 64 samples frame size version:
22064
You have to consider that port number in your router.
Hi Volker
Let me add my voice to the many thanking you for this software - it is a real gift to me and my bandmates.
I run Jamulus on Win10 using a Presonus audioBox 96. I tried out v3.4.5git, running the server and client on the same machine (127.0.0.1) . The good news is that the total delay dropped from 24ms to 13ms. However I found that there were many more dropouts, audible and shown as red flashes on the buffer led. I compared 3.4.4 to 3.4.5git with both set to 128 samples (double checked my ASIO panel) ; both reported a delay of 24ms but 3.4.5git had more dropouts. Even setting realtime priority and manually raising both jitter buffers on 3.4.5git yielded dropouts.
Let me know if there's anything I can do to help figure this out, even if I don't get a full 9ms reduction in latency any bit would help :)
Thanks for your feedback. Yes, I also noticed that I get more drop outs than with the 128 samples version. My bandmate even told me that he does not like the sound of the new version. He says that it is not as crisp as the 128 samples version (some high frequencies are missing).
So there are some things which have to be sorted out in that 64 samples version...
Hi Volker,
I did some FFT and frequency-response comparison between Jamulus128 and Jamulus64, all on your Central Server, both with buffer settings at 6 and High Quality Stereo Audio.
There is no difference in the Frequency-Response!
But as you see in the FFT, THD+N is much higher in the 64 Version.
I don´t know why exactly.
Regards
Manuel Skorupka
Wow, that is great. Thank you for the plots. Are you able to compile Jamulus? If yes, you could try out other OPUS quality settings and see if you can reach the THD+N of the 128 samples version.
Yes I'm able to compile. Can you give me a hint how and where the opus quality settings could be changed.
Great. Here is the code you have to change: https://github.com/corrados/jamulus/blob/master/src/client.h#L93
Currently High Quality Stereo is set to 72 coded bytes. Just increase this number to get a better quality.
I tried all values from 60 to 100 and also 142, 144, 248. The quality doesn't improve significant.
That is bad news. So it seems the OPUS audio quality reaches a natural bound at the very low frame size of 64 samples. So it seems to be a trade-off between audio quality and latency.
There is one more thing you could try. In this line: https://github.com/corrados/jamulus/blob/master/src/global.h#L133
you can replace it by #undef USE_LOW_COMPLEXITY_CELT_ENC. That increases the computational complexity of the encoder and therefore maybe we get a better audio quality.
I´ve made some new additional measurements with the hints you gave me.
'#undef USE_LOW_COMPLEXITY_CELT_ENC improves the audio quality.
In this mode the increase of 72 coded bytes improves audio quality too, to the point of 88. It seems that it brings down the noise a little bit.
Hi Volker again,
I also did an audio comparison between Jamulus 128 with high quality audio settings and Jamulus64 compiled with '#undef USE_LOW_COMPLEXITY_CELT_ENC on different settings. It´s all stored in a reaper project. I can´t hear a difference between the different versions of Jamulus. ;)
That's good news. So with help of this setting we can get the same quality for 64 as for 128 samples frame size. Have you checked the CPU load during your tests when you changed the USE_LOW_COMPLEXITY_CELT_ENC flag? Is it significant?
On the server i checked the Jamulus CPU load with htop.
On the clients (Raspberry Pi 4, Raspberry Pi 3B) i checked the CPU load with htop.
An my client on Win10 has 2,7% cpu load.
I can´t see any big differences beween the different Jamulus versions.
But i´dont know if that is an meaningful testing methode.
This test is good enough. Ok, so I conclude that for 128 everything is fine as it is and for 64 we need to set "#undef USE_LOW_COMPLEXITY_CELT_ENC".
You have done a lot of quality tests recently. If we use 64 with "#undef USE_LOW_COMPLEXITY_CELT_ENC", do you think the number of coded bits of 72 is a good number? Or do you recommend to increase that number.
The problem is that with 72, I am already close to the maximum upload rate of my internet connection. So I still have a slight headroom but the number should be as low as possible.
I´ve also measured the data throughput with different numbers of coded bits for up- and downstream:
35 --> 464 KBit/s
72 --> 680 KBit/s
87 --> 784 KBit/s
I think that 72 is good enough. But for me I made a Jamulus Version with 35, 72 and 87 number of coded bytes. Because I will never use the low quality mode.
Thanks, I have considered your advice in the following commit: https://github.com/corrados/jamulus/commit/5a05bf6a2f8c11a7d61575abfb2f7c3688eb274b
Hi Volker
Same effect here. Constant dropout scraping noise unless I set bother jitter buffers to around 1.
The dropouts are caused by your computer not having enough CPU to sample at a high rate with a small block size. If you have a new iMac Pro with 16 cores you shouldn't have any drop outs. I have a 6 core i7 and do not get drop outs when I set audio quality on medium/low. Also make sure nothing else is running on your computer taking cpu slices as that will cause less timeslicing to jamulus and thus dropouts.
Hi Simon
I think your suggestion is reasonable, but Task Manager indicated my CPU usage was only~20%. I did notice that the "System Interrupts" process was often highest on the list of processes sorted by CPU. I have turned off every "optional" program in my start up menu and set Jamulus to "Realtime" so it may just be too much for my machine.
Hey, is there a compiled mac binary of 64 to test?
A friend and I are hoping to use it for a session tomorrow, and while I run windows he only has access to mac.
Unfortunately, I don't have access to one to compile it with xcode, and he doesn't have the time to go through all of the steps to compile it.
Thanks!
Sorry, no Mac version for this test version available.