A new Jamulus software version is available: 3.5.12. Here are the changes:
added hyperlink support for the chat window, coded by jc-Rosichini (#591)
added new menu entry "Clear All Stored Solo Settings" (#616)
fade in all clients at the server when entering a server to avoid the volume
is at 100% when joining a server (#628)
added a qmake CONFIG flag for disabling the automatic version check (#370)
avoid confusion with the Server Address field on the connection setup window by
no longer showing the server name in that field since it is only intended for
entering IP addresses or valid server URLs (#365)
removed the "Show Creative Commons BY-NC-SA 4.0 Licence Dialog" setting from the
server GUI and changed the -L/--licence text in the licence dialog to "Do you agree
to the text in the chat window?" so that a licence text must now be given in the
server welcome message (#587, #367, #81)
added a protocol message for a reduced server list to improve the situation caused
by UDP packet fragmentation (#631, #255)
added translation: Slovak by jose1711 (#635)
bug fix: crash when using the jam recorder in the server, coded by pljones (#618)
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unfortunately, I just found a known issue with the newest release: https://github.com/corrados/jamulus/issues/657. The reduced server list is shown instead of the normal list but the reduced list should only be shown if large UDP packets do not come through (which is not the case for me since the old version 3.5.11 works fine).
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you again for all the great work on Jamulus, what a fantastic platform for real time playing!
I just upgraded from 3.5.8 to 3.5.12 and noticed an increase of roughly 2x in overall delay. I have two clients running on separate PCs in my house, one of the PCs is also running the server. I've upgraded the PC with client and server to 3.5.12, the other PC is still running 3.5.8. Both clients connect to the server PC IPv4 LAN address. Ping times are 0 ms almost all the time, and occasionally show 1 or 2 ms.
With 3.5.8 running everywhere my overall delay in both clients is typically 18 to 22 ms, I've seen this consistently since 3.5.8 was released. With the server and client on one PC running 3.5.12 I see a typical overall delay in both clients of 35 to 45 ms.
I've worked my way back through previous releases, and I see this same additional delay issue with versions 3.5.11 and 3.5.12, but do not see it in 3.5.10 and earlier versions. It appears to be related to the server since both clients show the additional delay and one of the clients is always 3.5.8.
Both clients use a buffer delay of 5.33 ms with small network buffers enabled, jitter buffer auto is enabled, audio quality is high. Changing audio quality to normal did not improve the overall delay. Both PCs are fairly capable Windows 10 desktop builds, one runs a Core i7-6700K, the other a Core i7-9700K. Both have 32GB RAM and Samsung EVO PCIe SSDs.
Does anyone have any idea why I might be seeing this additional delay? Thank you in advance for any insight or guidance you can offer. I think my next step is to grab an oscilloscope and measure delay to see how the actual and reported delays line up. Based on reported jitter buffer numbers I suspect the delay increase is real. I will follow up when I have actual delay information.
Apologies in advance if this is not the proper forum for this issue. I don't know enough about the issue at this point to claim it's a bug, but it feels like an issue that could be best addressed by the developers.
Matt
Last edit: Matt Barr 2020-10-12
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've just tested this on Windows 10, client connected to server on localhost, Buffer at 5.33ms, ASIO buffer size = 512.
I get the asme overall delay of 20-21ms (initially 25-27 on first few seconds after connection) using both 3.5.12 and 3.5.10. I've not tested combinations though (so client 3.5.10 and server 3.5.12 for example). Do you mean the effect you're seeing is only when a newer client connects to an older server?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you so much for confirming this on your end. I was seeing this with 3.5.11/12 server, regardless of client version. Yesterday I confirmed reported overall delay numbers with a scope. It appeared that instead of settling to 2 or 3 jitter buffers it would stay at 6 or 7 for some reason, and was repeatable across reinstallations and reboots.
Today I started up the 3.5.12 server and client on same PC and it quickly settled into the expected 20 ms overall delay. I have no idea why it behaved differently yesterday, I haven't made any driver or system changes, nor was I running anything yesterday that isn't running today. Any external network activity that might be responsible should not be version specific. Very strange, but I'm happy to see the expected overall delay with the latest version.
I've uploaded a scope image of a mic tap, waveforms were captured at PC audio connectors. Reported delay in client settings is 19 ms, scope shows 19.3 ms, fantastic. The reported overall delay numbers in the settings window look to be spot on, fantastic.
Thanks again for looking at this, and apologies for what appears to be a false alarm. I have no idea why I was consistently getting higher jitter buffer numbers yesterday. Bravo to the Jamulus developers, so well thought out and executed in terms of function, features, performance and stability.
I don't know if this is related, but I have noticed that with the last 2 or 3 versions the server list with their ping times takes a long time to show the lower ping times I used to have. It has always been that the ping times shown started at about twice the time that became stable after several seconds. Now it seems this takes more like 15 or 20 seconds to get down to the stable value.
I thought that was probably some strangeness at my ISP, but maybe it is not the ISP's fault.
👍
1
Last edit: DonC 2020-10-12
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Matt,
Another thought; since (I think) 3.5.10 the connect window is not updated if you hover over it to make it easier to pick a certain server. If you hover over the window all the time it is never updated so you only see the first ping time measured.
Be sure you have the cursor outside the connect window and see what you get for ping times then.
Of course if you are talking about the times shown in the settings window, then it is something else.
Another thought, are you running the same driver? ASIO4ALL is about 20ms slower than my nativer driver.
Don
Last edit: DonC 2020-10-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Don, thank you for this. I was referring to numbers in the settings window. I don't think there was a problem with the ping time or delay numbers updating, I could see them changing, and delay followed jitter buffer count as you'd expect. I also see that it sometimes takes several 10s of seconds for the auto jitter buffer settings to settle in, but sometimes it happens very quickly. I believe that has been the case for the four or so months I've been using Jamulus.
I am indeed using ASIO4ALL. I don't use it with an audio interface or other external device, I'm using it with the audio devices on my Gigabyte main boards and get 19 to 22 ms overall delay in the two clients I run. I've tried it with a cheap external USB audio adapter and the delay was terrible, adding 20 or 25 ms as you said. I have the luxury of being the guy who runs the server, others connect to the server through their ISPs but my client connections are LAN, so I tend to have the lowest latency even with the ASIO4ALL handicap!
I've been tempted to experiment with a Scarlett or similar to see what kind of delay improvement I get, but have not done so. I use a vocal mic and wireless instrument (sax) mic connected to my old Mackie 808M PA head, tape out from the PA head goes to PC main board line in which is the ASIO4ALL input. Our weekly jams are basically like studio sessions, it's just amazing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A new Jamulus software version is available: 3.5.12. Here are the changes:
added hyperlink support for the chat window, coded by jc-Rosichini (#591)
added new menu entry "Clear All Stored Solo Settings" (#616)
fade in all clients at the server when entering a server to avoid the volume
is at 100% when joining a server (#628)
added a qmake CONFIG flag for disabling the automatic version check (#370)
avoid confusion with the Server Address field on the connection setup window by
no longer showing the server name in that field since it is only intended for
entering IP addresses or valid server URLs (#365)
removed the "Show Creative Commons BY-NC-SA 4.0 Licence Dialog" setting from the
server GUI and changed the -L/--licence text in the licence dialog to "Do you agree
to the text in the chat window?" so that a licence text must now be given in the
server welcome message (#587, #367, #81)
added a protocol message for a reduced server list to improve the situation caused
by UDP packet fragmentation (#631, #255)
added translation: Slovak by jose1711 (#635)
bug fix: crash when using the jam recorder in the server, coded by pljones (#618)
Nice! How does the hyperlink support for the chat window work? My http links don't do anything when clicked on. Is https only supported?
Yes, that's what we decided. Only https is supported.
Thank you very much for your work!!
Regards,
Unfortunately, I just found a known issue with the newest release: https://github.com/corrados/jamulus/issues/657. The reduced server list is shown instead of the normal list but the reduced list should only be shown if large UDP packets do not come through (which is not the case for me since the old version 3.5.11 works fine).
Clarification for users (including me) who are new to Linux and the command line: "--licence /" is included on a line in the jamulus.service file.
Last edit: Charlie Channel 2020-10-12
Hello all,
Thank you again for all the great work on Jamulus, what a fantastic platform for real time playing!
I just upgraded from 3.5.8 to 3.5.12 and noticed an increase of roughly 2x in overall delay. I have two clients running on separate PCs in my house, one of the PCs is also running the server. I've upgraded the PC with client and server to 3.5.12, the other PC is still running 3.5.8. Both clients connect to the server PC IPv4 LAN address. Ping times are 0 ms almost all the time, and occasionally show 1 or 2 ms.
With 3.5.8 running everywhere my overall delay in both clients is typically 18 to 22 ms, I've seen this consistently since 3.5.8 was released. With the server and client on one PC running 3.5.12 I see a typical overall delay in both clients of 35 to 45 ms.
I've worked my way back through previous releases, and I see this same additional delay issue with versions 3.5.11 and 3.5.12, but do not see it in 3.5.10 and earlier versions. It appears to be related to the server since both clients show the additional delay and one of the clients is always 3.5.8.
Both clients use a buffer delay of 5.33 ms with small network buffers enabled, jitter buffer auto is enabled, audio quality is high. Changing audio quality to normal did not improve the overall delay. Both PCs are fairly capable Windows 10 desktop builds, one runs a Core i7-6700K, the other a Core i7-9700K. Both have 32GB RAM and Samsung EVO PCIe SSDs.
Does anyone have any idea why I might be seeing this additional delay? Thank you in advance for any insight or guidance you can offer. I think my next step is to grab an oscilloscope and measure delay to see how the actual and reported delays line up. Based on reported jitter buffer numbers I suspect the delay increase is real. I will follow up when I have actual delay information.
Apologies in advance if this is not the proper forum for this issue. I don't know enough about the issue at this point to claim it's a bug, but it feels like an issue that could be best addressed by the developers.
Matt
Last edit: Matt Barr 2020-10-12
Hi Matt - I'll see if I can reproduce this (other welcome to do so too!), and if so we should probably raise it on the Github issues list.
I've just tested this on Windows 10, client connected to server on localhost, Buffer at 5.33ms, ASIO buffer size = 512.
I get the asme overall delay of 20-21ms (initially 25-27 on first few seconds after connection) using both 3.5.12 and 3.5.10. I've not tested combinations though (so client 3.5.10 and server 3.5.12 for example). Do you mean the effect you're seeing is only when a newer client connects to an older server?
Thank you so much for confirming this on your end. I was seeing this with 3.5.11/12 server, regardless of client version. Yesterday I confirmed reported overall delay numbers with a scope. It appeared that instead of settling to 2 or 3 jitter buffers it would stay at 6 or 7 for some reason, and was repeatable across reinstallations and reboots.
Today I started up the 3.5.12 server and client on same PC and it quickly settled into the expected 20 ms overall delay. I have no idea why it behaved differently yesterday, I haven't made any driver or system changes, nor was I running anything yesterday that isn't running today. Any external network activity that might be responsible should not be version specific. Very strange, but I'm happy to see the expected overall delay with the latest version.
I've uploaded a scope image of a mic tap, waveforms were captured at PC audio connectors. Reported delay in client settings is 19 ms, scope shows 19.3 ms, fantastic. The reported overall delay numbers in the settings window look to be spot on, fantastic.
Thanks again for looking at this, and apologies for what appears to be a false alarm. I have no idea why I was consistently getting higher jitter buffer numbers yesterday. Bravo to the Jamulus developers, so well thought out and executed in terms of function, features, performance and stability.
I don't know if this is related, but I have noticed that with the last 2 or 3 versions the server list with their ping times takes a long time to show the lower ping times I used to have. It has always been that the ping times shown started at about twice the time that became stable after several seconds. Now it seems this takes more like 15 or 20 seconds to get down to the stable value.
I thought that was probably some strangeness at my ISP, but maybe it is not the ISP's fault.
Last edit: DonC 2020-10-12
Hi Matt,
Another thought; since (I think) 3.5.10 the connect window is not updated if you hover over it to make it easier to pick a certain server. If you hover over the window all the time it is never updated so you only see the first ping time measured.
Be sure you have the cursor outside the connect window and see what you get for ping times then.
Of course if you are talking about the times shown in the settings window, then it is something else.
Another thought, are you running the same driver? ASIO4ALL is about 20ms slower than my nativer driver.
Don
Last edit: DonC 2020-10-13
Hi Don, thank you for this. I was referring to numbers in the settings window. I don't think there was a problem with the ping time or delay numbers updating, I could see them changing, and delay followed jitter buffer count as you'd expect. I also see that it sometimes takes several 10s of seconds for the auto jitter buffer settings to settle in, but sometimes it happens very quickly. I believe that has been the case for the four or so months I've been using Jamulus.
I am indeed using ASIO4ALL. I don't use it with an audio interface or other external device, I'm using it with the audio devices on my Gigabyte main boards and get 19 to 22 ms overall delay in the two clients I run. I've tried it with a cheap external USB audio adapter and the delay was terrible, adding 20 or 25 ms as you said. I have the luxury of being the guy who runs the server, others connect to the server through their ISPs but my client connections are LAN, so I tend to have the lowest latency even with the ASIO4ALL handicap!
I've been tempted to experiment with a Scarlett or similar to see what kind of delay improvement I get, but have not done so. I use a vocal mic and wireless instrument (sax) mic connected to my old Mackie 808M PA head, tape out from the PA head goes to PC main board line in which is the ASIO4ALL input. Our weekly jams are basically like studio sessions, it's just amazing.