Need coffee as its 08:30 here yawn !
Got chores to do etc. Be back later when I can
Thank you, johnV,
This is great. To summarize for people:
Codec is set to LPCM 1ch 16bit
Sample rate 48k
Duplex is Half (but this might be ignored, I can’t remember where we left it)
Audio System is set to Qt Audio
Latency is set about 25%
And you are using speakers and mic over USB, possibly a headset. Looks like your OS is Windows 10 or Windows 11.
It’s good to hear that you are able to keep the audio connection flowing. Perhaps others can replicate your settings on their setup.
Enjoy that coffee, off for my second espresso right now…
–E
de W6EL
Hi John,
The screenshot shows WFView audio out and in to be going to a USB Codec - this is often a USB-connected bridge within a radio - do you have the X6100 connected to your PC via USB as well as over the network?
73 Ed.
There is no USB connection to the pc at all, Just PSU lead and dongle to router and antenna. Just a thought, I may have when I received the x6100 that I tried to connect it to the pc briefly, just testing the ports, but that was 6 months ago 'ish.
Thanks John,
That USB Codec shown must be your USB headphones perhaps? In any case, your configuration sounds identical to mine but with me no matter what I do, the audio stops after 1 minute (almost exactly 1 minute). I can see no errors in any of the logs that might explain what is happening. I wonder if this might be caused by something else that I have installed on my Windows 11 PC.
73 Ed.
Hi, I suggest you make sure there is nothing else running that will use the resources the radio and wf view need . There may be something running in the background as well ie apps and other other software, perhaps even something like logbooks etc. Try disconnecting headphones and any other cables attached to the pc…
Got to walk my dog and things to do.
Do you have the screen saver on your PC turned on? Any time the PC screen goes into sleep you will have MS turn off your audio connection. I have mine set to NEVER and the problem goes away.
Paul
Hi Paul, Thanks John.
No screensaver Paul, but … the fact that the audio cuts exactly after 60 seconds, I think I might know what it is. I use “FreeFileSync” to back up changes to an external pair of drives and that checks … every 60 seconds!
Looking at the version of that software which I installed some time ago on Windows 10, there have been several updates, some related to Windows 11 it seems - so I have upgraded to the latest version and I will try WFView again. Fingers crossed! If this now works reliably, with FFS running. If not I will temporarily stop FFS and try again.
If the result is positive I’ll go back to trying to have WFView work via WiFi rather than cabled Ethernet.
73 Ed DD5LP.
just got back !! Where is that cuppa ? Dont forget the M$ option to place your hd’s in sleep / low power to “'er save the planet NOT !”
Well, that was interesting …
Having updated the FreeFilesync to the latest version, WFView stopped working. The program will load and the log says it found the radio and started the UDP stream - no errors, but also no display from the radio on the PC and definitely no audio.
So I stopped FreefileSync completely rebooted and tried again - no difference.
This would suggest that FFS has overwritten a common DLL used by WFView.
OK - so I de-installed WFView (with FFS still disabled), rebooted and re-installed WFView. Reboot. Retry, no change WFView does not display any data from the radio.
This suggests to me, that the additional files that were loaded on my initial install of WFView (MS C++ runtime I think) may be the key here and are the ones that have been overwritten by FFS.
This is turning into a bigger job …
73 Ed DD5LP.
UPDATE: after a complete de-install of FFS and WFView and re-installing WFView (without FFS installed), the problem of audio-dropout in WFView is still there - so the conflict seems was not FreeFileSync. Looking in Task Manager, there are many system-related threads but no applications that I can see that would execute and cause the audio dropout after exactly 60 seconds.
Have you got a laptop that you can try ?. This will certainly prove that the radio or its setup is the issue. Are you using a 32bit version of the software on a 64bit pc by any chance or VV ? You can also check the various threads running under M$
This like most people’s Personal Computer these days is a laptop.
I am running the v 2.03 64 bit version of WFView on the 64bit version of Windows 11 Pro.
I have also run the 32 and 64-bit V 1.64 versions of WFView on the laptop and the same audio dropout occurs.
73 Ed.
Try if you can getting another x6100 and see if that has an issue. How old is that x6100 ? Send it back as a dud hi hi. Could the problem be a dodgy port on the laptop ? There are a lot of dodgy connectors as we see in amateur radio from bnc, to sma, to phono plugs etc etc. The internet is flooded with chinese junk
Hi John,
Actually, these messages should be in the other thread (my bad) - as I have a new X6200, not an X6100.
So that looks like no one has the audio working for over a minute between an X6200 and the WFView Windows client but you have this working fine with an X6100.
Logically therefore the different part is the WFServer implementation within the X6200 when compared to the X6100.
73 Ed.
Me thinks send it back. Was this purchase just after the release of the x6200? Perhaps its a bad batch and if still in warranty I think sending it back could be the only solution.
The radio hardware is fine, but the Linux/network configuration may need some tweaking to get the UDP audio to work correctly. It sounds like from your example, that the WFView Server build in the X6100 has been tweaked so that it works, the X6200, not yet.
73 Ed.
Hi all,
Phil, I still owe you an answer regarding the maxed-out CPU:
“Depending on the version of htop, you should be able to tell it to display ‘custom thread names’.”
While I can enable the checkbox under Options, the display unfortunately remains unchanged.
Turn on “Tree” view first. Then scroll down to the wfview server process and see what it says beneath it.
The tree view was a good suggestion, but the result doesn’t really make things any clearer - at least not for me. The process that’s eating up (more than) a full core? Yeah, that would be … keyboard. 
(Edit: wrong screenshot)
That is super interesting.
Can you share the contents of /etc/xgradio/wfserver.ini?
Use three back ticks around the text (three on top, three on the bottom) to avoid awful formatting.
–E
de W6EL