3.8.0 on Windows 10 : problem with loopback (127.0.0.1)

[pcar75]

Bonjour,

I upgraded from 3.6.2 to 3.8.0 on my Windows 10 tower.
No problem with installation.
However, as I always test my setup with loopback before going out on sessions, I now get weird results.

1. On local server (127.0.0.1) Ping = 0-1 ms but Overall Delay = 39-40 ms (was 20-23 in 3.6.2), Jitter led is X-Red. Jitter Buffer (auto) = 11 (local) and 2 (server) (were 2-3 and 2 in 3.6.2).

2. Sound quality = lots of gurgling noise when there is sound.

3. On Psilly (public server, same city, OVH cloud, Linux, 3.8.0 recently) Ping = 16-20 ms, Overall Delay = 48-51ms (similar to 3.6.2) . Jitter Buffer on Auto = 3 local and 6 server ; a bit less noise when raising them 1 notch or 2 manually.

4. Much less gurgling than with loopback.

5. Other HW /SW settings unchanged. Jamulus : Channel (stereo), Quality (Normal), Enable small buffer (checked), Jitter Delay (5.33ms)

6. ASIO parameters unchanged (Behringer Q802USB, unsupported native driver, 2009).

I've observed this behavior yesterday and today mid-afternoon (UTC-4) , with a couple of hard reboot each time. I will try this evening again with the public sever just to verify that with my ISP I really get similar (or better) results than previous evening sessions with 3.6.2.

Has anyone else observed this ?

[pcar75]

Similar behavior tonight (19H30).

On 127.0.0.1 : Ping = 1 , OD = 39-41, JitterLed=solid Red, Jitter Buffer auto levels = 11 (local) & 2 (server) with much gargling noise.

• Server call = "C:\Program Files\Jamulus\jamulus.exe" -s -F -T -w " ... MyWelcomeMessage.HTML"

On same public server : Ping = 16 , OD = 47, JitterLed=G/Y/r, Jitter Buffer auto levels = 2 (local) & 6 (server).

?!?!

[dcorson-ticino-com]

I just checked on my Win10 system using 3.8.0 server and client.
I do have more slightly more jitter when connecting to 128.0.0.1 than I used to.
The jitter connected to a server "out on the net" is, however, as always.
It seems to me we have seen this before and it was related to a Win10 update.
That gurgling sound has to do with data packets arriving in the wrong order. We introduced code to correct the order when possible a while ago and have been hearing much less of that.
Note that you have a high jitter on the up-connection to that server which might indicate a communication problem there. Is it the same for other servers?
Are you running other programs in the background that may be causing processor loading?

[pcar75]

Err... I believe the address is 127.0.0.1 (not 128. ...).

I remember too that code was implemented to re-order packets.

??? "high-connection jitter on the up-connection to that server" ??? These values seems usual to me since 3.6.0. Same ISP-cable provider as before ...

Testing on nearby (similar ping) servers, I get no better result than with 3.6.2 .

Name / connect list ping / Connected ping & Overall Delay / JitterBuffer (auto) local & and server
Psilly / 11 / 15 & 46 / 3 & 6
PCAS-Jam1 / 11 / 15 & 46 / 2 & 6
PFerver / 11 / 15 & 47 / 4 & 6
LostAnglers / 17 ms / 23 & 55 / 3 & 6

I've asked our drummer with his Windows 7Pro (64b) Jamulus 3.8.0 laptop to test his private server; will report his findings. But it' not looking good for private server !!!

[ghost]

See what happens when you don't enable small buffers on the client, also don't use -F on the server.
Try 127.0.0.x [x=1,2,3,4,...] or even 127.z.y.x

[pcar75]

I have run and documented a 2nd run of tests ...

Context :

Tower with Windows10Pro : i7, 16GB Ram, 256GB SSD (OS+SW @50%), 1TB HD(Data @40%)
Audio : Guitar and voice to Behringer802USB mixer with native ASIO driver (2009, unsupported), Jamulus 3.8.0 (previously 3.6.2)
Jamulus client and ASIO set to 5.33ms, Enable small buffers, Channel = stereo, Quality = normal.

• But to have as simple and clean an environment as possible most of my sessions are based from the JamulusOS 2.0 USB keys (linux) with Jamulus 3.6.2.

Summary of Windows tests 2021-06-11-16h15 (Montreal, QC, Canada; UTC-4):

• Test server 3.8.0 loopback (127.0.0.1), PC physically disconnected from router. Almost no difference in delay and quality.
• Results
  Ping/Overall Delay/JitterBufferLed/JitterBufferLevels @auto local,server/Subjective quality
  -- Client Small Buffers (SB)= yes; Server SB = yes
  ---0-1/23-26/Green-some red/2-3,2/occasional random pop,crackle
  -- Client SB = no; Server SB = yes
  ---0-1/23-26/Green-some red/2-3,2/occasional random pop,crackle
  -- Client SB = yes; Server SB = no
  ---0-1/23-24/Green-some red/2,2/occasional random pop,crackle
  -- Client SB = no; Server SB = no
  ---0-1/23-24/Green-some red/2,2/occasional random pop,crackle

[gene96817]

If the link has no jitter, you also would not see any differences from the different test cases. Another possible reason that there are no differences in results for each test case is that the jitter condition can be handled by the smallest SB choice. The larger buffer options are there to handle larger jitter conditions.

[pcar75]

HOWEVER ...

1. With Windows, I usually stop certain programs from running and always test my setup with loopback before going to internet session. On 2nd tests run, I had started loopback session, omitting to stop Folding@Home*. Everything with loopback was behaving as well as 3.6.2, until I realised Folding@Home was still running. When I stopped this program, and repeated some tests I got the same disastrous results in loopback as in the 1st tests run. My best explanation so far is a) it's sorcery b) it's unknown quantum effects; I have doubts on the first one and appreciate any help.

With Folding@Home stopped ...
-- Client Small Buffers (SB)= yes; Server SB = yes
---0-1/40-42/solid red/11,2/constant gurgling noise when playing
-- Client SB = no; Server SB = yes
---0-1/39-42/solid red/11,2/constant gurgling noise when playing
-- Client SB = yes; Server SB = no
---0-1/26-29/many red/4-5,2/somewhat less gurgling noise when playing
-- Client SB = no; Server SB = no
---0-1/37-39/many red/9,2/somewhat less gurgling noise when playing

2. Another Player told me he has worse performance and quality with loopback (3.8.0) than with public server. He is on Linux, but he had never tested loopback before so cannot compare with previous version of Jamulus. So I'll keep using my Jamulus OS 2.0 (Linux) with Jamulus 3.6.2. for a while.

*foldingathome.org : this a distributed/grid computing software that consumes unused CPU cycles to evaluate proteins for fighthing desease like COVID: the client part basically consists of a background calculating module and a browser-based gui with status and controls.
I have it configured to run at low CPU (51%, no GraphicPU) . No audio is involved.

[ghost]

One more try:
Comment out line 59 in /src/server.cpp:
Timer.setTimerType ( Qt::PreciseTimer );
see #1536

[pcar75]

I find this very mystifying too. It seems to have been introduced by a Win10 update, not a change in Jamulus.

I had the same Modus Operandi before and nerver experienced this problem in 3.6.2. ...!?!?

[ghost]

If this is the fault of a Win10 update, then Jamulus 3.6.2 should have the same problem as Jamulus 3.8.0 now.
Is this the case?

[pcar75]

@DavidSavinkoff
Since no one else has reported on this problem, I may uninstall 3.8.0 -after careful backup, restore points, etc.- but how do I get 3.6.2 (64b) reinstalled on Windows10 ?
I can only find source code in < > Code.

[ghost]

It appears that you have to use SourceForge to get older packages.
Note that reinstalling Jamulus 3.6.2 is to determine whether it has this loopback problem (unless your objective is to downgrade).

SourceForge provides sha1 and md5 checksums
(see the (i) icon at the end of the filename line)

https://sourceforge.net/projects/llcon/files/Jamulus/3.6.2/
I believe the Windows download is for 32 and 64 bit CPUs

https://sourceforge.net/projects/llcon/files/Jamulus/
extra fyi.

[pcar75]

I ran tests again this afternoon for loopback and 2 public servers. Same conclusion :

Local loopback tests yield results worse that public ones, and more loaded systems (ex. running Folding@Home) yield better performance than less loaded ones for loopback !"

Here are the results in MS Excel 97/2000/XP (.xls) format (i.e. also ok for Open/LibreOffice).
Tests Jamulus 380.xls

Note that manually changing the jitter buffer level of local to 4, 3 ,2 (from 11 on auto) does not change the sound quality problem.

[pcar75]

After backing up (with larger external disk) , I de-installed 3.8.0 and re-installed 3.6.2.
I have identical problems with loopback to the ones already reported, tested with FoldingAtHome (FAH) running and stopped.
So it seems that one or more Windows update might be the culprit.

HOWEVER ...

[pcar75]

I have another problem.
After de-installing 3.6.2 and re-installing 3.8.0.
The Installer would not install in the C:\Program Files\Jamulus directory !?!? (2 of my text files left) I renamed the directory with ".bak".
Then, it installed OK but when launching the program, I get an error that MSVCP140_01.dll is not to be found ! Message suggests to re-install , but same error happens again !
There are versions of this dll in C:\Windows\SysWOW64 (this is not in PATH environment variable !?!) , in C:\Fichiers de Programme (x86)\Audacity and in C:\Windows\Installer\$PatchCache$\Managed\6BA....

[pcar75]

I doubt I'm the 'Choosen-One-And-Only' by Microsoft to experience the loopback problem and that nobody else uses the client in loopback to their server. And for the new problem, a similar missing dll has already been reported (VCRUNTIME140_1.dll , #1843).

If it can help , I've included a snippet of changes in Windows at the time (2021-06-09) I've installed 3.8.0.
Modifications auto de Windows_20210609.csv

Thanks for any help.

[ann0see]

Yes, this missing dll issue seemed to come up recently. I think it can be fixed by removing the ms redistributable and installing it again manually

[ghost]

• Check to see if any software packages were installed after the first time you installed Jamulus-3.6.2
• The Jamulus packaging for Windows has had many changes between Jamulus 3.6.2 and 3.8.0 (code churn lately)

[pcar75]

@DavidSavinkoff

• Besides these recent tests, I have not manually installed new software since Jamulus 3.8.0 ( ±2021-06-09 ) and the file previously uploaded contains the last journal entry to this day. Note that I'm not very familiar with the administration tools (i.e. Event viewer) of Windows10 , so I just sent what made the most sense to me.
• I will attempt a component reinstall as per Windows instruction ( https://support.microsoft.com/en-us/topic/the-latest-supported-visual-c-downloads-2647da03-1eea-4433-9aff-95f26a218cc0 )

Do I need to install only x64... or also x86... ?

EDIT: CANCEL THIS ! I followed pljones and henkdegroot suggestions in #1843 (n.b. expand some comments) .

[pcar75]

@DavidSavinkoff

#@!$% Now Bandlabs's Cakewalk is complaining that it can't find CONCRT140.dll !!!
I'm definitely not in the mood for dll hell ! Been there done that !

[ghost]

@pcar75 Change your CMOS battery first (probably a CR2032). Then suspect a failing hard drive or controller.

[pcar75]

The second problem (MSVCP140_1.dll and CONCRT140.dll) solved with help from pljones and henkdegroot ( #1843). It consisted of uninstalling "Microsoft Visual C++ 2015-2019 Redistributable (x64)" with Windows app control , uninstalling and re-installing 3.8.0.

Initial client-server in loopback problem still present.

@DavidSavinkoff Thanks ! I hadn't though about the CMOS battery but it's a definite possibility as I've had weird problems in the past with other PCs whose cause was that.

[pcar75]

@DavidSavinkoff : Although I have my Windows 10 tower being wiped clean, reinstalled and checked (incl. the motherboard battery), the Windows 10 laptop that I temporarily use behaves similarly with Jamulus 3.6.1. and the same ASIO-Behringer hw setup.
Public server performance is understandably a bit lesser than with my tower, but loopback tests with this local server yields the same disappointing results. So it is not a battery problem, but a Windows 10 update conflict with Jamulus code.

Unless Jamulus developers/maintainers find a solution, this may be the end of usable Windows 10 client+private server for most people ? I doubt MS will correct the situation even with Windows 11.

[ghost]

Try this ipaddr: 127.3.14.159 to see if it works better than 127.0.0.1

No joy, try this:
ipconfig /all
at the command line.

Your computer's IPv4 ipaddress(es) displayed there.
Try the ip address that is associated with the interface your server is using.
(e.g. You may have a Wireless ipaddr, and an Ethernet ipaddr.)

[pcar75]

Thanks David, but on this laptop, same problems whether I use 127.0.0.1, or the LAN IP address of ethernet card given by ipconfig. With 127.3.14.159, the client shows "TRYING TO CONNECT" indefinitely.

As for my tower , it does not have WiFi capacity. I will probably spend the week reinstalling my favorite softwares but I doubt newer tests on it will show better results.

[ghost]

I'm thinking that linux will be the only functioning operating system because the others are turning into "subscription appliances". BTW 127.3.14.159 works on linux.
Microsoft has obviously 'hooped' the network interface.

[ghost]

Try the following to see if it helps:
https://jamulus.io/wiki/Tips-Tricks-More#using-quality-of-service-on-windows

And/Or see what you can do with your firewall (127.0.0.1 should be trusted)
(Microsoft Windows comes with a Microsoft Firewall, you don't need to purchase a 3rd party firewall)

[pcar75]

I got my pc tower back , wiped clean (literally and figuratively) and re-installed and I'm completing my other software setup.

@DavidSavinkoff : Thanks again, but the Group Policy mod does not work for me. I followed exactly the page's instructions and after rebooting I got every public server at >500 ms and then Jamulus crashed. I deleted the gpedit rule and everything went back to before. I also verified my Windows Firewall ; it had the proper (UDP) rules for input and output for "Jamulus.exe" except one for TCP which I deactivated.

[pcar75]

Well ! After lots of tests and a complete overhaul of my pc tower, I believe that Windows 10 for Jamulus loopback session ( client+server ) are a thing of the past ; unless you run foldingathome simultanously , which is really odd but does cure the problem of constant gurgling noise, high overall delay and high local Jitter Buffer level.

My best wishes to curious developers :-o