I just released a new Jamulus version 3.5.0. The biggest change is that it can use 64 samples frame size OPUS packets if the sound card buffer size is also set to 64 samples (or any buffer size < 128 samples). If the Jamulus server is started with the -F command line argument and the Jamulus client uses 64 samples sound card buffer size, the entire system runs on 64 samples and you can expect lower overall latencies.
Note that the Default Central Server already runs with the -F flag.
Important note: If you set the sound card buffer size to 64 samples, it may happen that you do not get audio back from the server if the server version is older then 3.4.7. This is because older server versions do not support the 64 samples OPUS packets. If you want to play at these servers, you have to switch your sound card buffer size to 128. Then you can play on these servers, too.
👍
6
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Volker. I've just upgraded my server to 3.5.0 and used the -F flag, as soon as I brought it up the fader meters stopped working, they work fine when the -F flag is not present? Is that known?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In addition to my reply yesterday I have to admit that I only tried the 3.5.0 windows client on an Jamulus server on Ubuntu. Today I did some tests with the 3.5.0. server on windows, conclusion, the Ubuntu-Jamulus-server outperformed the Windows-Jamulus-server by far!!
A difference in Overall delay off 10 to 15 ms .
(and yes, I'm using an 'audio tuned' version of windows 10 and no, client and server where running not on the same machine )
Thank God there's Linux :-) .
Last edit: Luuk 2020-04-17
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I had my first rehearsal with my band using the 3.5.0 version. Unfortunately we had problems with the small 64 OPUS packets. We had a lot more drop outs. As a workaround the sound card buffer could be set to 128 to use the old OPUS packets but it would prevent to use very small sound card buffers and at the same time use the old 128 sample OPUS packets.
For the next Jamulus version I will then introduce an additional switch in the settings dialog where you can explicitely select that you want to use the low latency OPUS64 packets. This setting will be OFF by default. I think that should improve the situation.
At the same time I found out that running the server with the -F option did work very good. The problems were only on the client side.
Did you have similar experiences with the new 3.5.0 Jamulus version? Would be interesting to hear your feedback.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I installed the 3.50 and after that I have no sound in jamulus. I even reïnstalled 3.47 but now there is no sound there too... I checked and the settings in Jamulus are still the same as when it was working (I had a screenshot). So perhaps I messed something up with normal audio settings.
Before jamulus starts I can hear my piano and mic entering at the auxilary output of my soundcard. As jamulus runs, nu sound. only when I change the ASIO setup (creative audio settings) I get half a second of sound and its gone again....
Running Win10 on a 2nd gen i5, creative ZS2 soundcard,
Windows sound settings : OUT speakers creative, IN Analog mix.
Curious detail: the mic test in windows sound settings lights up when I play, but not in jamulus.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Volker, after a few hours of trying, i decided to connect anyway. As soon as I connected, I had sound, and the level-leds were blinking. But I thought these should also be working when disconnected? I don't know what the problem was/is but, for now we can play! Nice weekend!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Volker,
First, I love Jamulus! Playing with other musicians with diferent instruments from across the ocean is giving me a lot of joy. Thank you all for providing it. I just bought a bluetooth earset, which works wilth all other programs on my pc, but not with Jamulus. Any thoughts?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Bluetooth has a high latency. It will not work with Jamulus anyway. Please use a Headphone with a cable.
---------------------------------------------
New Jamulus Release 3.5.0 https://sourceforge.net/p/llcon/discussion/software/thread/8a61883f61/?limit=25#2ea3/2f77
---------------------------------------------
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/llcon/discussion/software/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
At the risk of sounding like a jackass: wouldn't there be a comparatively strong use case to offer 120 samples of frame size? That's the smallest standard frame size of Opus. Encoder/decoder are optimised to word with standard frame sizes, Opus files (as far as I can tell) can only use standard frame sizes: using 120 samples would allow server-side recording of a standard Opus file straight from the incoming frames without decompression or (lossy) recompression. RTP and similar encapsulation protocols appear to work wth standard buffer sizes (and libraries working those with smart rate adaption and asynchronous I/O are also available) and may be prioritised for Internet routing purposes. A timer resolution of 2.5ms is a lot more likely to be well-supported by an operating system than a timer resolution of 2.56ms.
I find that ASIO drivers for 48kHz sampling frequency often offer a sample size of 48*2^n. Matching this sample period of 1ms to buffers of 2.5ms length is a better fit than matching it to buffers of 2.56ms length.
And there is quite a bit of potential for synergies with other technology when one uses a standard (and self-descriptive) rather than a custom frame size for Opus.
The ability to use a smarter RTP library for transmission and jitter buffering could offset some of the larger latency incurred here. Strictly speaking, the definitely incurred latency is just a single frame (2.5ms instead of the 1.333ms of a 64-sample frame) though the bandwidth of the connections and various processing stages, depending on the respective available CPU power, adds to that.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just released a new Jamulus version 3.5.0. The biggest change is that it can use 64 samples frame size OPUS packets if the sound card buffer size is also set to 64 samples (or any buffer size < 128 samples). If the Jamulus server is started with the -F command line argument and the Jamulus client uses 64 samples sound card buffer size, the entire system runs on 64 samples and you can expect lower overall latencies.
Note that the Default Central Server already runs with the -F flag.
Important note: If you set the sound card buffer size to 64 samples, it may happen that you do not get audio back from the server if the server version is older then 3.4.7. This is because older server versions do not support the 64 samples OPUS packets. If you want to play at these servers, you have to switch your sound card buffer size to 128. Then you can play on these servers, too.
Hi Volker. I've just upgraded my server to 3.5.0 and used the -F flag, as soon as I brought it up the fader meters stopped working, they work fine when the -F flag is not present? Is that known?
Ignore that, I just logged out the room and went back in and it works,.
Hi Volker, just used the 3.5.0. with my bandmates. It works great, what a big improvement! The overall delay time decreases with 6 to 11 ms! Thanks!!
Last edit: Luuk 2020-04-16
Is there are way to set buffer size on macOS Catalina? I found online that "macOS applications should have this option".
In addition to my reply yesterday I have to admit that I only tried the 3.5.0 windows client on an Jamulus server on Ubuntu. Today I did some tests with the 3.5.0. server on windows, conclusion, the Ubuntu-Jamulus-server outperformed the Windows-Jamulus-server by far!!
A difference in Overall delay off 10 to 15 ms .
(and yes, I'm using an 'audio tuned' version of windows 10 and no, client and server where running not on the same machine )
Thank God there's Linux :-) .
Last edit: Luuk 2020-04-17
I had my first rehearsal with my band using the 3.5.0 version. Unfortunately we had problems with the small 64 OPUS packets. We had a lot more drop outs. As a workaround the sound card buffer could be set to 128 to use the old OPUS packets but it would prevent to use very small sound card buffers and at the same time use the old 128 sample OPUS packets.
For the next Jamulus version I will then introduce an additional switch in the settings dialog where you can explicitely select that you want to use the low latency OPUS64 packets. This setting will be OFF by default. I think that should improve the situation.
At the same time I found out that running the server with the -F option did work very good. The problems were only on the client side.
Did you have similar experiences with the new 3.5.0 Jamulus version? Would be interesting to hear your feedback.
I installed the 3.50 and after that I have no sound in jamulus. I even reïnstalled 3.47 but now there is no sound there too... I checked and the settings in Jamulus are still the same as when it was working (I had a screenshot). So perhaps I messed something up with normal audio settings.
Before jamulus starts I can hear my piano and mic entering at the auxilary output of my soundcard. As jamulus runs, nu sound. only when I change the ASIO setup (creative audio settings) I get half a second of sound and its gone again....
Running Win10 on a 2nd gen i5, creative ZS2 soundcard,
Windows sound settings : OUT speakers creative, IN Analog mix.
Curious detail: the mic test in windows sound settings lights up when I play, but not in jamulus.
3.5.1 should hopefully fix that: https://sourceforge.net/p/llcon/discussion/software/thread/3ba7d356d7/
Make sure not to enable "Enable Small Network Buffers" than you should be fine.
Hi Volker, after a few hours of trying, i decided to connect anyway. As soon as I connected, I had sound, and the level-leds were blinking. But I thought these should also be working when disconnected? I don't know what the problem was/is but, for now we can play! Nice weekend!
uninstall first?
Hi Volker,
First, I love Jamulus! Playing with other musicians with diferent instruments from across the ocean is giving me a lot of joy. Thank you all for providing it. I just bought a bluetooth earset, which works wilth all other programs on my pc, but not with Jamulus. Any thoughts?
Bluetooth has a high latency. It will not work with Jamulus anyway. Please use a Headphone with a cable.
Aha. Thank you; I'll continue to use the headphone with cable.
At the risk of sounding like a jackass: wouldn't there be a comparatively strong use case to offer 120 samples of frame size? That's the smallest standard frame size of Opus. Encoder/decoder are optimised to word with standard frame sizes, Opus files (as far as I can tell) can only use standard frame sizes: using 120 samples would allow server-side recording of a standard Opus file straight from the incoming frames without decompression or (lossy) recompression. RTP and similar encapsulation protocols appear to work wth standard buffer sizes (and libraries working those with smart rate adaption and asynchronous I/O are also available) and may be prioritised for Internet routing purposes. A timer resolution of 2.5ms is a lot more likely to be well-supported by an operating system than a timer resolution of 2.56ms.
I find that ASIO drivers for 48kHz sampling frequency often offer a sample size of
48*2^n. Matching this sample period of 1ms to buffers of 2.5ms length is a better fit than matching it to buffers of 2.56ms length.And there is quite a bit of potential for synergies with other technology when one uses a standard (and self-descriptive) rather than a custom frame size for Opus.
The ability to use a smarter RTP library for transmission and jitter buffering could offset some of the larger latency incurred here. Strictly speaking, the definitely incurred latency is just a single frame (2.5ms instead of the 1.333ms of a 64-sample frame) though the bandwidth of the connections and various processing stages, depending on the respective available CPU power, adds to that.
Uh, where I write 2.56ms, replace this with 2.666ms. Just shows how confusing 64 samples at 48kHz end up...