Matt Barr

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....

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...

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...

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...

Hi Kieran, It is useful to have the MP3 track connect to the server as a separate client so that each client has its own volume fader for the MP3 track. Otherwise you're dependent on the MP3 source to balance MP3 volume with some other audio source. This will also give you a separate MP3 track if you're recording from the server, and allows you to use a separate client name like Ringo for drum tracks. I've solved this problem by using a second PC in my home. I run a Jamulus client and media player,...

Hi Kieran, It is useful to have the MP3 track connect to the server as a separate client so that each client has its own volume fader for the MP3 track. Otherwise you're dependent on the MP3 source to balance MP3 volume with some other audio source. This will also give you a separate MP3 track if you're recording from the server. I've solved this problem by using a second PC in my home. I run a Jamulus client and media player, and use a physical cable to connect the PC media player output jack to...

Yes, and not hard. With the 5.18.00 version of the old IDE, at line 128 in C:\SiLabs\MCU\INC\compiler_defs.h I have: #if defined SDCC #if (SDCC >= 300) I changed this to: #if defined SDCC || defined __SDCC #if (SDCC >= 300 || __SDCC_VERSION_MAJOR >= 3) I have to confess to not understanding the beauty or advantage in omitting the SDCC definition. There are still a good number of SDCC-specific definitions added to the command line by sdcc.exe, and retaining SDCC=NNN maintains compatibility with the...

Yes, and not hard. With the 5.18.00 version of the old IDE, at line 128 in C:\SiLabs\MCU\INC\compiler_defs.h I have: #if defined SDCC #if (SDCC >= 300) I changed this to: if defined SDCC || defined __SDCC if (SDCC >= 300 || __SDCC_VERSION_MAJOR >= 3) I have to confess to not understanding the beauty or advantage in omitting the SDCC definition. There are still a good number of SDCC-specific definitions added to the command line by sdcc.exe, and retaining SDCC=NNN maintains compatibility with the...