Is putting --fastupdate in the command line the same as checking the enable small network buffers checkbox on the client?
Does it do anything for a server?
Just wondering.
Don
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Do you meant putting --fastupdate on the command line for a client? If so, I believe it only has an effect for servers. To make use of it on the client, you need to check the small network buffers box.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am wondering because I thinking was that the server would follow the setting on the client. Then why have the --fastupdate option at all ?
I assume that the servers that don't work with the small network bufers checkbox set are so old that the don't know what to do.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When connecting to a server with --fastupdate enabled, small network buffers may or may not improve things (depends on the client's network quality and CPU speed I think), so it needs to be a client option, I believe.
However, I'm unsure why some server operators would not want to enable --fastupdate. It may because it implies more bandwidth use perhaps.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
3.4.7 (2020-04-11)
- added support for 64 samples frame size in the server (if server runs in 64 or 128 samples
mode it is still compatible to both, 64 and 128 samples frame size clients)
3.5.0 (2020-04-15)
- added support for 64 samples OPUS packets in the client (if a sound card buffer size
larger or equal than 128 samples is chosen, the legacy 128 samples OPUS packets are used)
3.5.1 (2020-04-18)
- added Enable Small Network Buffers switch to enable small sound card buffers in
combination with legacy OPUS packets since OPUS packets with 64 samples enable low
latency but can increase audio drop outs
improved auto jitter buffer for 64 samples frame size
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
see Topic: HOWTO install Jamulus as a "headless" server on Ubuntu 18.04
Volker Fischer - 2020-05-09
The default timer update is 2.66 ms (128 samples at 48 kHz). If you use --fastupdate, the timer update is set to 1.33 ms (64 samples at 48 kHz). This is to reduce the overall delay for clients which support the "Enable Small Network Buffers" and run with 64 samples sound card buffer delay or shorter.
But even with the --fastupdate enabled, your server is still compatible to old Jamulus client versions. I have implemented buffer conversions for that case.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, so that means that without the -F the server is using 128 sample buffers even with 64 sample buffer clients.
I wil add that to my server command line and see if I see a difference.
Thanks for the info.
Don
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've installed Jamulus on a cloud server and I'm desparately trying to lower my latency as I live about 140 miles from the cloud. I used the command "sudo systemctl start jamulus -f and while the server didn't throw an error message, I'm concerned that because I used a lowercase "F", nothing will change. Can some please confirm that is has to be a capital F? The server is Unbuntu 18.04
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First of all, thank you for responding so soon and thanks for creating this program!!
Regarding the capital F, I tried that and got an error message which is why I tried the lower case "f"
Without wasting your time, is there a command or a way I can determine if the lower case "f" is actually having any effect? (or if it's working, should the sound or latency difference be that obvious?)
Also, can you give me a general idea how far away I can be from a server and still expect to be able to play with people with lower than 30 ms delay? (I saw your YouTube video and it seems that you and your band are spread over 150 miles and yet it seems to work for you. ) Thanks in advance for your help!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There is no lower case "f" defined. I have no idea why it works for you...
With running the server with -F you will only have an effect if in the client you also use 64 samples sound card buffer size and have Enable Small Network Buffers activated.
The delay depends on your internet provide and the internet route. You have to try it out yourself. It is hard to predict what you will get if you do not try it out.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think -F is referring to the startup option for jamulus process not for "systemctl <whatever> -f " = force, meaning shutdown immediately amongst other things. You'll need to edit the you jamulus service startup file and add -F to the correct line. The line will be similar to the following with the -F option added. ../Steve</whatever>
Thanks again for your response. I'll go back in and try to get my cloud server to recognize the capital F. Regarding the delay, I've tried and while I am successful in connecting to the server, It's still slow despite the fact that I've upgraded my internet service. (400mb down - 20mb up) I'm still looking to improve the latency.
By the way, I see from your videos that you are a drummer using a Roland V-Drum kit. I am also a drummer and using a Roland V-Drum kit as well. Are you using your V-Drum module as your USB interface? If so, what are buffer settings and if so, what interface do you use?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Dennis - on the Hardware Setup page on the wiki, Volker says he was using the following setup on that video:
"I am using a Lexicon Omega USB audio card on a 2009 Mac Mini. My bandmates all use Windows 10 and have Behringer audio cards, e.g. the Behringer Xenyx 1204USB. My internet connection is 10 Mbps down / 1 Mbps upstream via DSL."
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is putting --fastupdate in the command line the same as checking the enable small network buffers checkbox on the client?
Does it do anything for a server?
Just wondering.
Don
Do you meant putting --fastupdate on the command line for a client? If so, I believe it only has an effect for servers. To make use of it on the client, you need to check the small network buffers box.
I am wondering because I thinking was that the server would follow the setting on the client. Then why have the --fastupdate option at all ?
I assume that the servers that don't work with the small network bufers checkbox set are so old that the don't know what to do.
When connecting to a server with --fastupdate enabled, small network buffers may or may not improve things (depends on the client's network quality and CPU speed I think), so it needs to be a client option, I believe.
However, I'm unsure why some server operators would not want to enable --fastupdate. It may because it implies more bandwidth use perhaps.
Looking at the changelog, the history here is:
3.4.7 (2020-04-11)
- added support for 64 samples frame size in the server (if server runs in 64 or 128 samples
mode it is still compatible to both, 64 and 128 samples frame size clients)
3.5.0 (2020-04-15)
- added support for 64 samples OPUS packets in the client (if a sound card buffer size
larger or equal than 128 samples is chosen, the legacy 128 samples OPUS packets are used)
3.5.1 (2020-04-18)
- added Enable Small Network Buffers switch to enable small sound card buffers in
combination with legacy OPUS packets since OPUS packets with 64 samples enable low
latency but can increase audio drop outs
see Topic: HOWTO install Jamulus as a "headless" server on Ubuntu 18.04
Volker Fischer - 2020-05-09
OK, so that means that without the -F the server is using 128 sample buffers even with 64 sample buffer clients.
I wil add that to my server command line and see if I see a difference.
Thanks for the info.
Don
Well that's a real easy way to reduce the overall delay by 3ms !
If you are running a server don't forget to set -F !
Don
Would be interesting to know why it's not on by default. I'm guessing there's a cost to using it.
I've installed Jamulus on a cloud server and I'm desparately trying to lower my latency as I live about 140 miles from the cloud. I used the command "sudo systemctl start jamulus -f and while the server didn't throw an error message, I'm concerned that because I used a lowercase "F", nothing will change. Can some please confirm that is has to be a capital F? The server is Unbuntu 18.04
Yes, it has to be a capital F -> "-F"
First of all, thank you for responding so soon and thanks for creating this program!!
Regarding the capital F, I tried that and got an error message which is why I tried the lower case "f"
Without wasting your time, is there a command or a way I can determine if the lower case "f" is actually having any effect? (or if it's working, should the sound or latency difference be that obvious?)
Also, can you give me a general idea how far away I can be from a server and still expect to be able to play with people with lower than 30 ms delay? (I saw your YouTube video and it seems that you and your band are spread over 150 miles and yet it seems to work for you. ) Thanks in advance for your help!
There is no lower case "f" defined. I have no idea why it works for you...
With running the server with -F you will only have an effect if in the client you also use 64 samples sound card buffer size and have Enable Small Network Buffers activated.
The delay depends on your internet provide and the internet route. You have to try it out yourself. It is hard to predict what you will get if you do not try it out.
I think -F is referring to the startup option for jamulus process not for "systemctl <whatever> -f " = force, meaning shutdown immediately amongst other things. You'll need to edit the you jamulus service startup file and add -F to the correct line. The line will be similar to the following with the -F option added. ../Steve</whatever>
ExecStart=/usr/local/bin/Jamulus -s -n -F -e jamulus.fischvolk.de -o "yourServerName;yourCity;[country ID]"
Thanks again for your response. I'll go back in and try to get my cloud server to recognize the capital F. Regarding the delay, I've tried and while I am successful in connecting to the server, It's still slow despite the fact that I've upgraded my internet service. (400mb down - 20mb up) I'm still looking to improve the latency.
By the way, I see from your videos that you are a drummer using a Roland V-Drum kit. I am also a drummer and using a Roland V-Drum kit as well. Are you using your V-Drum module as your USB interface? If so, what are buffer settings and if so, what interface do you use?
Hi Dennis - on the Hardware Setup page on the wiki, Volker says he was using the following setup on that video:
"I am using a Lexicon Omega USB audio card on a 2009 Mac Mini. My bandmates all use Windows 10 and have Behringer audio cards, e.g. the Behringer Xenyx 1204USB. My internet connection is 10 Mbps down / 1 Mbps upstream via DSL."