TX Audio bug

IC-7300, Rasbperry pi, wfview 1.6 server connected to Windows 11 PC (Dell XPS-17) running Wfview. RX audio works on Qt Audio and RT Audio. No TX audio on Qt Audio. On RT, the TX audio is distorted. This is a screenshot using the “Tune” function from WSJT-X:

This is most likely that the USB level is set too high, I find that this has to be set very low (it is around 50% on your screenshot).

Try reducing the USB level until you get a clean signal.

Phil

Thanks for the suggestion, but it didn’t work. The level drops when I turn down the USB gain, but it is still wideband junk being transmitted.

Now it seems RT audio is not working, but Qt works on RX. On TX, I see distortion with Qt sometimes, other times it does not work at all.

I see this error on the Raspberry PI:
ALSA lib pcm.c:8545:(snd_pcm_recover) underrun occurred

Also, Wfview crashes (or gets killed by Windows 11). The window just disappears with no warning or error message.

It all worked a few months ago, but I got busy and didn’t use it for a while. Installed the latest versions today and got stuck.

Chris W6COV

Hi Chris.

Various features have been added over the past few months. Most are optional, so make sure that cluster spots/usb controllers, and any other things you aren’t going to need are disabled on the server.

What model Pi are you using? I find that a Pi4 works well, but older Pi models may not have enough CPU/RAM.

We are looking at adding the capability to disable the local waterfall on the server (but still pass waterfall data to any clients) as drawing the waterfall is a very CPU intensive activity.

Phil

Sorry if it wasn’t clear, but my suspicion is that the Pi server is becoming ‘CPU bound’ this can cause all sorts of problems with audio (as it needs to be real-time)

One quite useful command to tell if this is the case is to run the following commands in a terminal (with wfview server running and a client connected)

ps ax | grep wfview
top -H -p <pid from previous command>

This will show all wfview threads (most are named for convenience) and which is using the most CPU. For a dual-core CPU, any thread using around 50% is going to be severely restricted. 25% for a quad-core like the Pi4.

You can also find which CPU core each thread is running on, but that’s a bit more complicated. While top is running, press “f” and look down the list for “P = Last Used Cpu (SMP)” Highlight that option and press “space” to select it, then press q to return to the top main screen. You will now have a column titled “P” which shows which CPU core is in use by that thread.

73 Phil M0VSE

Hi Chris

I have pushed a new branch called ‘tristate’ which changes the WF Enable checkbox to a tristate type as follows:

Off = Signal Radio to stop sending Waterfall data
On  = Signal Radio to start sending Waterfall data
Partial (1/2 checked) Ignore WF data but forward to clients

In my testing, setting Partial mode reduces CPU consumption by around 50% so on your Pi server, edit the wfview download/install script and enter the branch name “tristate” where indicated, then run the script again. It will download the updated branch and you can then try setting the WF Enabled checkbox to partially checked.

Your client should still receive the Waterfall data as normal

Once we have tested it a bit more thoroughly, I expect this update to make it into the master branch.

73 Phil M0VSE

Thanks. I’m running a PI Model 4 B. Here’s the output from top:

image

I’ll try to tristate branch.

Chris