Jamulus version 3.5.1. Here is a list of the changes:
added a Mute Stream button to hear your signal and the signal of the other clients but
do not transmit your signal to the server so that the other clients cannot hear you
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
upgrade OPUS codec library to v1.3.1 by doloopuntil
server list registration status indicator added to the server GUI, coded by pljones
improved auto jitter buffer for 64 samples frame size
the ping times in the server list are now more stable
👍
6
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks Volker, doloopuntil and pljones - 3.5.x it's a big improvement from the previusly 3.4 versions. Server/Client performance seems really better now and yet the open-music server on the raspberry pi4 it was so good that someone had Rec a jam and posted on youtube.
Last edit: Alessandro Rei 2020-04-20
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Volker thanks for this fine software, and for all the recent releases.
About this new Mute Stream button... Imagine if the client could automatically set it when feedback is detected locally ? The client could even pop up a friendly message to the user explaining that they should wear headphones because their microphone is very sensitive.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am unclear about the function of "Enable Small Network Buffers". When is it good to use this and when is it not good?
There are often more public servers listed than performers. I imagine many of us choose to run a Jamulus Server for our own band's use and not as a public service. The consequence is the Central Server(s) work unnecessarily hard and can fill up (200 limit). At this time, should the default for "Make My Server Public" be on (encouraging more public servers) or off (helping performers to create private servers). I even see some named "Private" as many do not understand how to operate privately.
Last edit: Nick Veit 2020-04-18
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you have a fast PC, a high quality audio interface and a fast, stable internet connection it is recommended to set "Enable Small Network Buffers". This lowers the overall delay. In most cases, enabling this will lead to more audio drop outs and more instable connection.
Creating a pure private server is not easy to setup. So some users decide to use the public list and just name it "private".
To solve the 200 servers limit, a new North America list was introduced. Unfortunately, I still can see a lot of USA and Canada servers listed in the Default Central Server.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks Volker. Surely a public and private server are equally easy to set up, the only difference being that performers need to connect by IP/domain name rather than using the list.
My point is that there are too many empty servers unnecessarily clogging up the Central Server List (same in US soon). If many of theswe servers are intended to be private people should be encouraged to switch off the option to list them.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
With every new version of Jamulus the experience of playing together online is getting better, the overall delay has drastically reduced, thanks for that!!!
The 3.5.1. version is working fine for me with the exception of the new 'Mute Stream' button.
When I press this button my own performance sounds distorted, I'm getting some kind of flanged or phaser sound. Even if I activate the 'Mute' button of my own channel, I'm getting that strange sound.
Anyone else is recognizing this??
Last edit: Luuk 2020-04-19
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Jitter Buffer, including differential settings for Local and Server
Enable Small Network Buffers on/off
Audio Channels setting
In order to stay simple I did not touch the 2.67 ms (64) packet size anymore.
Why the whole experiment: I had the feeling that keeping the Auto jitter buffer on, always leads to more "knacken" as the auto function seems to continously try to optimze with the consequence that the red dots appearing more frequently (in simple wording).
Intention was to generate some empirical evidence and maybe derive some hypotheses ... noting very scientific, but at least some simple research.
Beforehand - my setup is
Running Jamulus 3.5.1 both in server and in client mode, accessing my own server as a client (ping time 0-1ms)
Mac OS Catalina 10.15.3, 3.8 GHz Quad Core i5, 16GB 2400 MHz DDR4, Radeon Pro 580 8GB
Yamaha AG03 Audio Interface
Nord Electro 6 + Chat mic via headset input + Ipad (for Irealpro or music playalong) via Aux
Telekom VDSL50 internet via Ethernet cable ... not very stable in our vicinity, real values easily and erratically drop into the 20 MBit/s range
Apple Music running with my endless Jazzology playlist in repeat mode via (aux) input
Objective of my "study"
Target number for tweaking: overall delay + qualitative assessment of audible quality/breaks in sound/"knacken"
Parameter to track: red buffer dots
I tried to get as close to just some red buffer dots and would then increase respective jitter buffer sizes by just one notch
Results
I. Audio Channels
My band and I all thought we get the best results in overall audio quality with the Mono-in/Stereo-out setting
II. With Enable Network Buffers (and 64 packet size)
Local tweaked down to 6
Server tweaked down to 4
result - overall delay 16ms with little "knacken"
III. Without Enable Network Buffers (and 64 packet size)
Local tweaked down to 4
Server tweaked down to 3
result - overall delay 23ms with less "knacken" than under II.
As I said, not very sciecntific, but a start and some empirical data generated ... thoughts, comments, conclusions?
Last edit: Harro Heilmann 2020-04-19
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The size of the local and server jitter buffers must depend on both the local and server hardware being used and the network between them. I am pleased these settings worked for you, but they will vary for others. I also avoid auto, sometimes tweaking both local and server up by two clicks from the auto postion. I understand the local is for incoming buffering and the server for incoming to the server from you. Up means more latency, down means more break-up.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Volker, thanks for your amazing software. I've been looking for this for 15 years.
As I'm a new user with little actual experience using Jamulus for real I'll post my main suggestion for improving Jamulus here rather than complete your survey just yet:
is is possible to improve what happens when there is a bad dropout - occasionally I get a loud noise in my headphones. Some sort of more graceful degradation would be a huge improvement as the loud "bang" can be unpleasant. Maybe Jamulus could even send a second, low quality "backup" audio stream to help with the problem of data lost or severely delayed in transit?
The latency and overall sound quality are good though. (28ms overall delay with ping time to UK public server about 7ms, using wired LAN, 10Mbit broadband upload, MacOS 10.12.6 on 2012 Macbook pro, mono, high quality, 64 samples)
When I try the Enable Small Network Buffers option the Jitter Buffer LED goes red and I can't hear anything.
Vielen Dank nochmal, Giles
Last edit: Giles Kennedy 2020-04-19
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, I noticed that too. And I don't like that, too. I think it is worse with the 64 samples OPUS packets. I have this already on my list to take a look at...
When I try the Enable Small Network Buffers option the Jitter Buffer LED goes red and I can't hear anything.
I assume your internet upload bandwith is too small for the higher rate. Please look at the rate which is reported in the Jamulus settings dialog. Watch how it increases when you Enable Small Network Buffers.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It is better now I have a better upload speed (10 Mbit - 4 days ago I only had 1Mbit)). Usually I just have a moment of silence when there is a dropout, but very occasionaly a loud click noise instead.
With Audio Channels -> Mono and Audio Quality -> High and Buffers 64 or 128 I have Audio Stream Rate of 444kbps. If I enable Small Network Buffers then the stream rate is 672kbps, which should not be a problem for my improved 10,000kbps upload speed internet connection...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
thanks for your excellent work on Jamulus, especially over the last couple of weeks!
Here are my current thoughts and potential feature requests:
My main whish (80% priority) currently would be "only" a more stable audio overall (less dropouts/bubbles/"knacken"), and only the second concern (20%) would be improved latency (if that requires an even better ISP connection).
My experience from bringing our band online is, that depending on the individual ISPs and their routing, with some work it is possible to find a server location that gives you acceptable ping-times (even before your "64bit version"), but you will most likely always have 1-2 people in the band that have a overall weaker internet connection (in our case, the Vodafone / Kabeldeutschland Cable Network users are clearely more the issue than the (V)DSL users) and also cant change to another provider (e.g. in a lot of parts of Berlin DSL is still not available).
So I guess most bands will always have to work with these physical "bottlenecks" and therefore find the "lowest common denominator".
I also consider "Mono / Low" to be pretty good speaking of audio quality already. I dont know if your encoding framework has more settings, so maybe there could be even a setting with less bandwidth usage what might improve overall quality in case of weak uplinks?
Also usually only 1-2 tech savy people will be in each band (aka the "tech guy" of that band / group of users), it would be cool if you think about scenarios that support the tech guy getting the full band online. E.g. maybe you can also transmit the individual delay / buffer status LEDs and then show them next to each channel? So it would be quite easy to spot who in the group is the weakest link (and needs optimization efforts). An extended additional idea would be, that you offer another window in which one could see all the detail settings of all connected band members. That would simplify trouble shooting / trial-and-error a lot.
Thanks a lot
Sonicedge
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Did some extra tests with the "Mute stream" function. As already mentioned I'm getting a strange artifact in the sound when I activate "Mute stream'.
Here my (new) experiences:
The weird sound is especially noticeable at high tones (in my case snare and cymbals)
The strange sound is only noticeable when connected to a server (but not connected to a server this function would be useless anyway ;-) ) .
Muting your own (personal) channel too, doesn't make any difference, the strange sound remains.
Hopefully this problem will be solved in a future update.
Last edit: Luuk 2020-04-20
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I cannot reproduce your issue. Does anyone else have the same problem?
If the sound is like a flanger, that would be caused by adding the same audio signal together where one of them is slightly shifted in time. Maybe you add your stereo signal at some point (either in the analog stage or in the digital domain).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As promised, I've tried a different audio interface, a Zoom UAC-2 and I 'm sorry to say, I had the same result. Especially the high tones sounding somewhat harsh and thin, both at 64 and 128 samples.
Last edit: Luuk 2020-04-20
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As long as I'm the only musician suffering from it, don't bother too much.
I won't use the new button too often, because everyone wants to hear me drumming. :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Jamulus version 3.5.1. Here is a list of the changes:
added a Mute Stream button to hear your signal and the signal of the other clients but
do not transmit your signal to the server so that the other clients cannot hear you
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
upgrade OPUS codec library to v1.3.1 by doloopuntil
server list registration status indicator added to the server GUI, coded by pljones
improved auto jitter buffer for 64 samples frame size
the ping times in the server list are now more stable
Thanks Volker, doloopuntil and pljones - 3.5.x it's a big improvement from the previusly 3.4 versions. Server/Client performance seems really better now and yet the open-music server on the raspberry pi4 it was so good that someone had Rec a jam and posted on youtube.
Last edit: Alessandro Rei 2020-04-20
Volker thanks for this fine software, and for all the recent releases.
About this new Mute Stream button... Imagine if the client could automatically set it when feedback is detected locally ? The client could even pop up a friendly message to the user explaining that they should wear headphones because their microphone is very sensitive.
... I cannot find my way to the My profile anymore - I am sure it must be somewhere, but I cannot find it (Mite Stream has replaced My Profile button)
Menu->View
... aaah, thx - just found it a minute ago after looking for the "tenth" times - sorry, redundant question
Thanks, yet again! Two minor thoughts:
I am unclear about the function of "Enable Small Network Buffers". When is it good to use this and when is it not good?
There are often more public servers listed than performers. I imagine many of us choose to run a Jamulus Server for our own band's use and not as a public service. The consequence is the Central Server(s) work unnecessarily hard and can fill up (200 limit). At this time, should the default for "Make My Server Public" be on (encouraging more public servers) or off (helping performers to create private servers). I even see some named "Private" as many do not understand how to operate privately.
Last edit: Nick Veit 2020-04-18
If you have a fast PC, a high quality audio interface and a fast, stable internet connection it is recommended to set "Enable Small Network Buffers". This lowers the overall delay. In most cases, enabling this will lead to more audio drop outs and more instable connection.
Creating a pure private server is not easy to setup. So some users decide to use the public list and just name it "private".
To solve the 200 servers limit, a new North America list was introduced. Unfortunately, I still can see a lot of USA and Canada servers listed in the Default Central Server.
Thanks Volker. Surely a public and private server are equally easy to set up, the only difference being that performers need to connect by IP/domain name rather than using the list.
My point is that there are too many empty servers unnecessarily clogging up the Central Server List (same in US soon). If many of theswe servers are intended to be private people should be encouraged to switch off the option to list them.
With every new version of Jamulus the experience of playing together online is getting better, the overall delay has drastically reduced, thanks for that!!!
The 3.5.1. version is working fine for me with the exception of the new 'Mute Stream' button.
When I press this button my own performance sounds distorted, I'm getting some kind of flanged or phaser sound. Even if I activate the 'Mute' button of my own channel, I'm getting that strange sound.
Anyone else is recognizing this??
Last edit: Luuk 2020-04-19
Ok,
I have started with some manual tweaking of
In order to stay simple I did not touch the 2.67 ms (64) packet size anymore.
Why the whole experiment: I had the feeling that keeping the Auto jitter buffer on, always leads to more "knacken" as the auto function seems to continously try to optimze with the consequence that the red dots appearing more frequently (in simple wording).
Intention was to generate some empirical evidence and maybe derive some hypotheses ... noting very scientific, but at least some simple research.
Beforehand - my setup is
Running Jamulus 3.5.1 both in server and in client mode, accessing my own server as a client (ping time 0-1ms)
Mac OS Catalina 10.15.3, 3.8 GHz Quad Core i5, 16GB 2400 MHz DDR4, Radeon Pro 580 8GB
Yamaha AG03 Audio Interface
Nord Electro 6 + Chat mic via headset input + Ipad (for Irealpro or music playalong) via Aux
Telekom VDSL50 internet via Ethernet cable ... not very stable in our vicinity, real values easily and erratically drop into the 20 MBit/s range
Apple Music running with my endless Jazzology playlist in repeat mode via (aux) input
Objective of my "study"
Target number for tweaking: overall delay + qualitative assessment of audible quality/breaks in sound/"knacken"
Parameter to track: red buffer dots
I tried to get as close to just some red buffer dots and would then increase respective jitter buffer sizes by just one notch
Results
I. Audio Channels
My band and I all thought we get the best results in overall audio quality with the Mono-in/Stereo-out setting
II. With Enable Network Buffers (and 64 packet size)
Local tweaked down to 6
Server tweaked down to 4
result - overall delay 16ms with little "knacken"
III. Without Enable Network Buffers (and 64 packet size)
Local tweaked down to 4
Server tweaked down to 3
result - overall delay 23ms with less "knacken" than under II.
As I said, not very sciecntific, but a start and some empirical data generated ... thoughts, comments, conclusions?
Last edit: Harro Heilmann 2020-04-19
The size of the local and server jitter buffers must depend on both the local and server hardware being used and the network between them. I am pleased these settings worked for you, but they will vary for others. I also avoid auto, sometimes tweaking both local and server up by two clicks from the auto postion. I understand the local is for incoming buffering and the server for incoming to the server from you. Up means more latency, down means more break-up.
Hi Volker, thanks for your amazing software. I've been looking for this for 15 years.
As I'm a new user with little actual experience using Jamulus for real I'll post my main suggestion for improving Jamulus here rather than complete your survey just yet:
The latency and overall sound quality are good though. (28ms overall delay with ping time to UK public server about 7ms, using wired LAN, 10Mbit broadband upload, MacOS 10.12.6 on 2012 Macbook pro, mono, high quality, 64 samples)
When I try the Enable Small Network Buffers option the Jitter Buffer LED goes red and I can't hear anything.
Vielen Dank nochmal, Giles
Last edit: Giles Kennedy 2020-04-19
Yes, I noticed that too. And I don't like that, too. I think it is worse with the 64 samples OPUS packets. I have this already on my list to take a look at...
I assume your internet upload bandwith is too small for the higher rate. Please look at the rate which is reported in the Jamulus settings dialog. Watch how it increases when you Enable Small Network Buffers.
Thanks for your reply :D
It is better now I have a better upload speed (10 Mbit - 4 days ago I only had 1Mbit)). Usually I just have a moment of silence when there is a dropout, but very occasionaly a loud click noise instead.
With Audio Channels -> Mono and Audio Quality -> High and Buffers 64 or 128 I have Audio Stream Rate of 444kbps. If I enable Small Network Buffers then the stream rate is 672kbps, which should not be a problem for my improved 10,000kbps upload speed internet connection...
Dear Volker,
thanks for your excellent work on Jamulus, especially over the last couple of weeks!
Here are my current thoughts and potential feature requests:
My main whish (80% priority) currently would be "only" a more stable audio overall (less dropouts/bubbles/"knacken"), and only the second concern (20%) would be improved latency (if that requires an even better ISP connection).
My experience from bringing our band online is, that depending on the individual ISPs and their routing, with some work it is possible to find a server location that gives you acceptable ping-times (even before your "64bit version"), but you will most likely always have 1-2 people in the band that have a overall weaker internet connection (in our case, the Vodafone / Kabeldeutschland Cable Network users are clearely more the issue than the (V)DSL users) and also cant change to another provider (e.g. in a lot of parts of Berlin DSL is still not available).
So I guess most bands will always have to work with these physical "bottlenecks" and therefore find the "lowest common denominator".
I also consider "Mono / Low" to be pretty good speaking of audio quality already. I dont know if your encoding framework has more settings, so maybe there could be even a setting with less bandwidth usage what might improve overall quality in case of weak uplinks?
Also usually only 1-2 tech savy people will be in each band (aka the "tech guy" of that band / group of users), it would be cool if you think about scenarios that support the tech guy getting the full band online. E.g. maybe you can also transmit the individual delay / buffer status LEDs and then show them next to each channel? So it would be quite easy to spot who in the group is the weakest link (and needs optimization efforts). An extended additional idea would be, that you offer another window in which one could see all the detail settings of all connected band members. That would simplify trouble shooting / trial-and-error a lot.
Thanks a lot
Sonicedge
Did some extra tests with the "Mute stream" function. As already mentioned I'm getting a strange artifact in the sound when I activate "Mute stream'.
Here my (new) experiences:
Hopefully this problem will be solved in a future update.
Last edit: Luuk 2020-04-20
I cannot reproduce your issue. Does anyone else have the same problem?
If the sound is like a flanger, that would be caused by adding the same audio signal together where one of them is slightly shifted in time. Maybe you add your stereo signal at some point (either in the analog stage or in the digital domain).
As promised, I've tried a different audio interface, a Zoom UAC-2 and I 'm sorry to say, I had the same result. Especially the high tones sounding somewhat harsh and thin, both at 64 and 128 samples.
Last edit: Luuk 2020-04-20
Have you set the Audio Quality in Jamulus to High?
Yes
I am running out of ideas...
As long as I'm the only musician suffering from it, don't bother too much.
I won't use the new button too often, because everyone wants to hear me drumming. :-)
There is a problem with mute streams when people have a self volume of less than 100%, hitting mute stream appears to make it 100% again.
Can you please create an Issue on Github for that?