What is RX Latency and rtt? Audio droupouts

1

I am running wfview on a RPI4 (RPI4 as hotspot) over to an IC-705 connected to the RPI hotspot on wifi. When I run ping on the RPI itself to the IC-705 I get ping times of less than 2ms.

wfview is reporting RX Latency of between 200 and 300ms and rtt of less than 20ms.
packet loss is low, about 62 out of 128,000. These delay numbers are far higher than the ping time.

Although audio as received by WSJTx on the RPI seems fine, there are droupouts on TX audio getting to the RPI.

The wfview log looks like this:
2023-01-29 22:37:38.386 INF udp: udpAudio : sending request for missing packet : “0x1312”
2023-01-29 22:37:52.086 INF udp: udpAudio : sending request for missing packet : “0x15c1”
2023-01-29 22:37:55.587 INF udp: udpCivData : sending request for missing packet : “0xb1c1”
2023-01-29 22:37:55.588 INF udp: udpAudio : sending request for missing packet : “0x166e”
2023-01-29 22:37:56.186 INF udp: udpCivData : sending request for missing packet : “0xb206”
2023-01-29 22:37:56.186 INF udp: udpAudio : sending request for missing packet : “0x168d”
2023-01-29 22:37:57.386 INF udp: udpAudio : sending request for missing packet : “0x16ca”

To me it looks like there is something about wfview that isnt working right as if RPI ping time is fine, why does wfview seem to be having network problems?

What is RX Latency and rtt and why dont they match ping time as measured by the RPI?

Where do I go from here?

Thanks & 73,
Tom

2

Hi Tom.

RTT is round trip time, this is the time it takes for a periodic ‘test’ packet that is sent by wfview to receive a response from the radio. On my IC705 with the radio connected to my wireless network, I typically see values of 2-5ms. On my LAN connected radios, RTT is usually around 1ms. I rarely see dropouts on any of my rigs with Windows, Mac or Linux clients.

RX latency is the internal processing time of wfview (and your selected audio system). It is quite possible that the RPI4 is simply ‘running out of steam’ and this is causing your audio dropouts, although ANY packet loss of udpAudio is going to result in dropouts.

It is worth bearing in mind that ICMP (ping) packets are 64 byte packets which are sent every second, whereas the UDP audio stream is 1K+ byte packets sent every 20ms. There is a significant difference between the two and the latter requires a significant processing capacity on your wireless AP.

You can check whether any threads within wfview are CPU bound with the following commands:

ps ax | grep wfview
top -H -p <pid of wfview>

It is also worth checking the CPU usage of hostapd while wfview is running. Streaming UDP audio can be a very CPU intensive operation for all devices

73 Phil M0VSE

3

Just FYI, here are the stats for my development machine running wfview to my IC705 (laptop is wired and IC705 is connected to a Cambium Access Point approx. 3ft away from it!). I do see occasional peaks of up to 10-15ms of RTT, but no more, and zero packet loss.

image

This is the same laptop connected to my IC7610 (both connected to the same GB LAN)

image

73 Phil M0VSE

4

Thanks Phil!

I am not sure how it happened, but now my RX latency has improved…the stats now are:

RX Latency 5ms RTT 8ms and no lost packets at all.

The RX Latency number stays around 5ms but sometimes is colored red.

The log still shows requests for missing packets, and the audio is the same, no improvement.

Overall CPU usage as shown by the standard CPU usage monitor on the desktop never goes above 50% and mostly stays between 20 to 40%.

The commands you gave yield:

Threads: 13 total, 0 running, 13 sleeping, 0 stopped, 0 zombie
%Cpu(s): 16.6 us, 10.9 sy, 0.0 ni, 71.5 id, 0.1 wa, 0.0 hi, 1.0 si, 0.0 st
MiB Mem : 7898.9 total, 6974.2 free, 404.7 used, 520.0 buff/cache
MiB Swap: 100.0 total, 100.0 free, 0.0 used. 7125.1 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
13101 pi 20 0 574980 82748 60116 S 28.2 1.0 4:27.43 wfview
19929 pi 20 0 574980 82748 60116 S 7.6 1.0 0:39.38 udpHandle+
20003 pi 20 0 574980 82748 60116 S 2.3 1.0 0:11.51 rxAudio()
20004 pi 20 0 574980 82748 60116 S 2.3 1.0 0:12.14 QThread
20005 pi 20 0 574980 82748 60116 S 2.0 1.0 0:09.51 audioConv+
13370 pi 20 0 574980 82748 60116 S 1.7 1.0 0:16.10 rigComman+
20006 pi 20 0 574980 82748 60116 S 1.3 1.0 0:06.46 audioConv+
13299 pi 20 0 574980 82748 60116 S 1.0 1.0 0:07.59 threaded-+
13149 pi 20 0 574980 82748 60116 S 0.0 1.0 0:00.78 QXcbEvent+
13218 pi 20 0 574980 82748 60116 S 0.0 1.0 0:00.00 gmain
13220 pi 20 0 574980 82748 60116 S 0.0 1.0 0:00.00 gdbus
13240 pi 20 0 574980 82748 60116 S 0.0 1.0 0:00.00 QDBusConn+
13372 pi 20 0 574980 82748 60116 S 0.0 1.0 0:00.00 dxcluster+

Which at least to my untrained eye looks ok.

I did notice that the official Audio Configuration instructions:

Audio Configuration | wfview

are quite different from the procedure I used to form the virtual audio cables on the RPI which is basically:

pulseaudio --start
pacmd load-module module-null-sink sink_name=MyIcomA
pacmd load-module module-null-sink sink_name=MyIcomB

Taken from

I tried the “official” way to create the virtual audio cables but I couldn’t get that to form the cables.

Why is it that the “official” guide to the virtual audio cables is so much more involved than what is pictured in the youtube video I referenced? Is the official guide outdated?

I wonder whether this could be a problem with the virtual audio cables at this point as the network connection seems ok as does the CPU load (at least to my untrained eye).

73 & thanks again,
Tom

5

Hi Tom, yes those figures look OK to me, no single thread is saturating a CPU core.

Regarding the virtual audio cables, the example you provided relies on PulseAudio, which may (or may not) be installed by default on all linux distributions. The solution we provided uses the underlying ALSA API so is guaranteed to be supported in some way.

We will look to add the alternative PulseAudio commands as it is certainly easier. Sadly Linux audio is a bit of a mess, with lots of competing systems (ALSA, PulseAudio, PipeWire, JACK etc. etc.)

73 Phil M0VSE

6

I’ve just noticed, that RX latency looks far too low… Which Audio System are you using? I would generally recommend using Qt Audio as that should be the most stable.

Lost packets still indicate a network problem though…

73 Phil M0VSE

7

I have tried them all, but only Qt works at all…the rest are worse or dont work…they don’t show the cables…

No lost packets anymore.

It was really odd----somehow trying all the different network radio settings in wfview did something that basically eliminated my RX latency problem AND the lost packet issue…I don’t know how that was possible but thats what has happened. Still though I have the audio problem. Also I don’t understand why the official audio instructions dont work for me (I don’t get the audio options in wfview for the cables).

I know audio in the RPI is a nightmare----it took so much tweaking to get the home RPIs working (wFview is for my portable RPI).

73,
Tom

8

Hi Tom.

It’s quite possible (likely) that the version of PortAudio provided with your Linux distro doesn’t support PulseAudio, which is why the devices aren’t provided. Both RT Audio and PortAudio have received significant updates recently.

Not sure why the commands provided for virtual audio cables (loopback) didn’t work for you? Most likely they were written for a different Linux distro with slightly different devices/command syntax?

For audio settings, I would recommend using uLaw (8bit) audio @ 16 KHz sample rate. This will give almost identical audio to the default 16bit PCM @ 48 KHz, but result in around 1/6 of the required network bandwidth!

73 Phil M0VSE

9

The settings made no difference, and the latency looks good but sometimes flashes red even with the low numbers. I attached a screenshot:

image
image729×42 11.3 KB

Its at 150,000+ now and still no losses…but still the audio is glitchy.

I saw it suggested to start wsjtx first, but I can’t do that as wsjtx will complain that the rig is not active.

I am sure I am missing something simple here, but what it is I have no idea.

You said you thought the latency was too low----could it be that something is not running that should be?

10

Make sure you change to those recommended settings prior to making contact with the rig. That is, before pressing Connect in wfview.

I assure you, the uLaw 8 bit format at 16KHz should work fine. I regularly use my setup at the park with an LTE hotspot.

Even though wsjt-x complains, you should still try opening it first. This is because wsjt-x can set the audio format of the loopback device and then wfview will follow. Let it complain a little. It establishes the audio device connection right away when you open it.

Do you show any messages in your logs that might indicate a connection issue?

—E
de W6EL

11

Elliot I made all the changes, no difference noted. Starting wsjtx first made no difference, switching around the order to start the cables first and then wsjtx made no difference also.

I did some experimentation to confirm that the RPI hotspot wasnt the issue. I connected the RPI by ethernet to the home network, and connected the 705 via wifi to a home router only feet away and found the audio problem to be worse. On this setup, with the home wifi router there were lost packets, but not an excessive amount. This is markedly worse than when I had the RPI as the hotspot and the 705 connected to it where I have 0 lost packets. So at this point I am confident the hotspot isnt the issue.

I tuned up pulseaudio, making it “less nice” and turning off idle functions but there was no difference. I followed the pulse audio debugging here: PulseAudio - Debian Wiki but no improvements.

The log makes it look like there is some sort of connection problem, but I suspect this is not a connection problem at all but something else…perhaps something to do with ports in use on the RPI? Here is a log produced when I started wsjtx first. In the first connection the RPI was the hotspot and the ic-705 was connected to it by wifi, then I closed that connection and had the RPI connected by ethernet to the home network and the IC-705 connected by wifi to a router only about 3 feet away. I included the log at the end of this message.

I also did try connecting via USB cable and oddly found that wfiew’s waterfall would work, but I couldnt get any audio at all TO the IC-705. I did confirm the IC-705 audio settings were correct by switching to the audio direct to the “brown-burr” audio card in the 705 and did get a tone that way with wfview doing the PPT through hamlib.

Its interesting to me that only Qt Audio works at all and the rest are much worse and cant even produce a tone, only a pulsed buzzing. Also interesting is that the wsjtx tuning tone on Qt Audio via wifi is most of the time not “clean” but seems to have a low frequency component as well. The RPI is powered by an Anker 3amp draw power bank.

Is there any way you can post your working RPI setup image so I could burn that onto an SD and give it a whirl? At least then I could eliminate hardware as a cause.

I have been seduced by the dream of fully wireless field operation with no extra GPS, wifi dongle or hotspot and really it should work…

73,
Tom-N2YTF
(a new patreon supporter)
023-01-30 23:18:39.391 INF system: “wfview version: 1.58 (Git:7f97625 on Jan 25 2023 at 21:23:35 by pi@raspberrypi). Operating System: Raspbian GNU/Linux 10 (buster) (arm). Build Qt Version 5.11.3. Current Qt Version: 5.11.3”
2023-01-30 23:18:39.402 WRN default: QMetaObject::connectSlotsByName: No matching signal for on_textToSendEdit_returnPressed()
2023-01-30 23:18:39.504 INF system: Loading settings from “/home/pi/.config/wfview/wfview.conf”
2023-01-30 23:18:39.521 INF rigctld: started on port 4533
2023-01-30 23:18:39.521 INF gui: Got Audio Output from Settings: “MyIcomB”
2023-01-30 23:18:39.522 INF gui: Got Audio Input from Settings: “MyIcomA.monitor”
2023-01-30 23:18:39.526 INF audio: Audio device(s) found (*=default)
2023-01-30 23:18:39.669 INF audio: * ( 0 ) Input Device : “default”
2023-01-30 23:18:39.669 INF audio: ( 1 ) Input Device : “jack”
2023-01-30 23:18:39.669 INF audio: ( 2 ) Input Device : “pulse”
2023-01-30 23:18:39.669 INF audio: ( 3 ) Input Device : “usbstream:CARD=b1”
2023-01-30 23:18:39.670 INF audio: ( 4 ) Input Device : “usbstream:CARD=Headphones”
2023-01-30 23:18:39.670 INF audio: ( 5 ) Input Device : “alsa_output.platform-bcm2835_audio.analog-stereo.monitor”
2023-01-30 23:18:39.670 INF audio: ( 6 ) Input Device : “alsa_output.platform-bcm2835_audio.digital-stereo.monitor”
2023-01-30 23:18:39.670 INF audio: ( 7 ) Input Device : “MyIcomA.monitor”
2023-01-30 23:18:39.671 INF audio: ( 8 ) Input Device : “MyIcomB.monitor”
2023-01-30 23:18:40.013 INF audio: * ( 0 ) Output Device : “default”
2023-01-30 23:18:40.013 INF audio: ( 1 ) Output Device : “jack”
2023-01-30 23:18:40.013 INF audio: ( 2 ) Output Device : “pulse”
2023-01-30 23:18:40.013 INF audio: ( 3 ) Output Device : “sysdefault:CARD=b1”
2023-01-30 23:18:40.014 INF audio: ( 4 ) Output Device : “dmix:CARD=b1,DEV=0”
2023-01-30 23:18:40.014 INF audio: ( 5 ) Output Device : “dsnoop:CARD=b1,DEV=0”
2023-01-30 23:18:40.014 INF audio: ( 6 ) Output Device : “hw:CARD=b1,DEV=0”
2023-01-30 23:18:40.014 INF audio: ( 7 ) Output Device : “plughw:CARD=b1,DEV=0”
2023-01-30 23:18:40.014 INF audio: ( 8 ) Output Device : “usbstream:CARD=b1”
2023-01-30 23:18:40.014 INF audio: ( 9 ) Output Device : “sysdefault:CARD=Headphones”
2023-01-30 23:18:40.015 INF audio: ( 10 ) Output Device : “dmix:CARD=Headphones,DEV=0”
2023-01-30 23:18:40.015 INF audio: ( 11 ) Output Device : “dsnoop:CARD=Headphones,DEV=0”
2023-01-30 23:18:40.015 INF audio: ( 12 ) Output Device : “hw:CARD=Headphones,DEV=0”
2023-01-30 23:18:40.015 INF audio: ( 13 ) Output Device : “plughw:CARD=Headphones,DEV=0”
2023-01-30 23:18:40.015 INF audio: ( 14 ) Output Device : “usbstream:CARD=Headphones”
2023-01-30 23:18:40.016 INF audio: ( 15 ) Output Device : “alsa_output.platform-bcm2835_audio.analog-stereo”
2023-01-30 23:18:40.016 INF audio: ( 16 ) Output Device : “alsa_output.platform-bcm2835_audio.digital-stereo”
2023-01-30 23:18:40.016 INF audio: ( 17 ) Output Device : “MyIcomA”
2023-01-30 23:18:40.016 INF audio: ( 18 ) Output Device : “MyIcomB”
2023-01-30 23:18:40.016 INF default: Looking for inputs
2023-01-30 23:18:40.019 INF audio: “Client Audio input device MyIcomA.monitor found! "
2023-01-30 23:18:40.019 INF default: Looking for outputs
2023-01-30 23:18:40.021 INF audio: “Client Audio output device MyIcomB found! "
2023-01-30 23:18:40.025 INF audio: “Server Audio input device default found! "
2023-01-30 23:18:40.025 INF audio: “Server Audio output device default found! "
2023-01-30 23:18:40.521 INF system: Cannot prepare WF view without rigCaps. Waiting on this.
2023-01-30 23:18:40.536 INF rig: creating instance of rigCommander()
2023-01-30 23:18:40.537 INF udp: Starting udpHandler user: “N2YTF” rx latency: 30 tx latency: 30 rx sample rate: 16000 rx codec: 1 tx sample rate: 16000 tx codec: 1
2023-01-30 23:18:40.538 INF cluster: starting dxClusterClient()
2023-01-30 23:18:40.539 INF udp: UDP Stream bound to local port: 36919 remote port: 50001
2023-01-30 23:18:40.623 INF system: Received CommReady!!
2023-01-30 23:18:40.623 INF default: Setting rig state for wfmain
2023-01-30 23:18:40.624 INF default: Setting rig state
2023-01-30 23:19:01.347 INF udp: Closing UDP stream : “10.0.0.143” : 50001
2023-01-30 23:19:02.788 INF udp: Starting udpHandler user: “N2YTF” rx latency: 30 tx latency: 30 rx sample rate: 16000 rx codec: 1 tx sample rate: 16000 tx codec: 1
2023-01-30 23:19:02.790 INF udp: UDP Stream bound to local port: 42984 remote port: 50001
2023-01-30 23:19:02.793 INF system: Received CommReady!!
2023-01-30 23:19:02.794 INF default: Setting rig state for wfmain
2023-01-30 23:19:02.795 INF default: Setting rig state
2023-01-30 23:19:03.894 INF udp: udpHandler : Received I am here from: QHostAddress(”::ffff:192.168.1.24”)
2023-01-30 23:19:03.895 INF udp: udpHandler : Received I am here
2023-01-30 23:19:03.898 INF udp: udpHandler : Received I am here from: QHostAddress(”::ffff:192.168.1.24”)
2023-01-30 23:19:03.898 INF udp: udpHandler : Received I am here
2023-01-30 23:19:03.903 INF udp: udpHandler : Received I am ready
2023-01-30 23:19:03.903 INF udp: udpHandler : Sending login packet
2023-01-30 23:19:03.908 INF udp: udpHandler : Received I am ready
2023-01-30 23:19:03.908 INF udp: udpHandler : Sending login packet
2023-01-30 23:19:03.910 INF udp: Got connection type: “FTTH”
2023-01-30 23:19:03.911 INF udp: udpHandler : Token response did not match, sent: 64361 got 51047
2023-01-30 23:19:03.911 INF udp: udpHandler : Detected connection speed FTTH
2023-01-30 23:19:03.917 INF udp: Got connection type: “FTTH”
2023-01-30 23:19:03.917 INF udp: udpHandler : Received matching token response to our request
2023-01-30 23:19:03.917 INF udp: udpHandler : Detected connection speed FTTH
2023-01-30 23:19:03.924 INF udp: udpHandler “Received radio capabilities, Name: IC-705, Audio: ICOM_VAUDIO, CIV: a4, MAC: 00:90:c7:0e:84:4b CAPF: 5001”
2023-01-30 23:19:03.924 INF udp: Got Connection status for: IC-705 Busy: 0 Computer IP “0.0.0.0”
2023-01-30 23:19:03.925 INF udp: Got Radio 0
2023-01-30 23:19:03.925 INF udp: Find available local ports
2023-01-30 23:19:03.926 INF default: Received serial port baud rate from remote server: 19200
2023-01-30 23:19:03.926 INF system: Delay command interval timing: 75 ms
2023-01-30 23:19:03.933 INF udp: Starting udpCivData
2023-01-30 23:19:03.933 INF udp: UDP Stream bound to local port: 45751 remote port: 50002
2023-01-30 23:19:03.934 INF udp: Starting udpAudio
2023-01-30 23:19:03.934 INF udp: UDP Stream bound to local port: 34937 remote port: 50003
2023-01-30 23:19:03.935 INF audio: Input audio handler starting: “MyIcomA.monitor”
2023-01-30 23:19:03.935 INF audio: Output audio handler starting: “MyIcomB”
2023-01-30 23:19:03.936 INF udp: udpHandler Got serial and audio request success, device name: “IC-705”
2023-01-30 23:19:03.936 INF audio: Input thread id 0x96844380
2023-01-30 23:19:03.937 INF audio: Output thread id 0x97045380
2023-01-30 23:19:03.937 INF audio: Output start() running
2023-01-30 23:19:03.937 INF udp: Got Connection status for: IC-705 Busy: 1 Computer raspberr-wfview IP “192.168.1.212”
2023-01-30 23:19:03.938 INF udp: Got Connection status for: IC-705 Busy: 1 Computer raspberr-wfview IP “192.168.1.212”
2023-01-30 23:19:03.938 INF udp: udpCivData : Received I am here
2023-01-30 23:19:03.939 INF audioconverter: Starting audioConverter() Input: 2 Channels of 0 48000 SignedInt 16 Output: 1 Channels of 1 16000 SignedInt 16
2023-01-30 23:19:03.940 INF audioconverter: wf_resampler_init() returned: 0 resampleRatio: 0.333333
2023-01-30 23:19:03.940 INF audio: Input start() running
2023-01-30 23:19:03.941 INF udp: udpAudio : Received I am here
2023-01-30 23:19:03.994 INF audioconverter: Starting audioConverter() Input: 1 Channels of 1 16000 SignedInt 16 Output: 2 Channels of 0 48000 SignedInt 16
2023-01-30 23:19:04.014 INF audioconverter: wf_resampler_init() returned: 0 resampleRatio: 3
2023-01-30 23:19:04.031 INF rig: Using incomingCIVAddr: (int): 164 hex: “0xa4”
2023-01-30 23:19:04.031 INF serial: Received rigCapabilities for “IC-705”
2023-01-30 23:19:04.032 INF rig: Have rig ID: decimal: 164
2023-01-30 23:19:04.033 INF rigctld: Got rigcaps for: “IC-705”
2023-01-30 23:19:04.044 INF system: Delay command interval timing: 25 ms
2023-01-30 23:19:07.894 INF udp: udpAudio : sending request for missing packet : “0xc5”
2023-01-30 23:19:16.597 INF rigctld: session connected: 33
2023-01-30 23:19:17.795 INF udp: udpCivData : sending request for missing packet : “0x72f”
2023-01-30 23:19:18.194 INF udp: udpCivData : sending request for missing packet : “0x777”
2023-01-30 23:19:18.294 INF udp: udpCivData : sending request for missing packet : “0x777”
2023-01-30 23:19:22.794 INF udp: udpAudio : sending request for missing packet : “0x3ab”
2023-01-30 23:19:42.794 INF udp: udpCivData : sending request for missing packet : “0x1527”
2023-01-30 23:19:51.895 INF udp: udpAudio : sending request for missing packet : “0x959”
2023-01-30 23:20:12.894 INF udp: udpAudio : sending request for missing packet : “0xd76”
2023-01-30 23:20:15.094 INF udp: udpCivData : sending request for missing packet : “0x26f4”
2023-01-30 23:20:27.994 INF udp: udpAudio : sending request for missing packet : “0x1068”
2023-01-30 23:20:30.997 INF udp: udpCivData : sending request for missing packet : “0x2fdc”
2023-01-30 23:20:34.471 INF udp: Got Connection status for: IC-705 Busy: 0 Computer IP “0.0.0.0”
2023-01-30 23:20:36.697 INF udp: CIV Watchdog: no CIV data received for 2s, requesting data start.
2023-01-30 23:20:36.699 INF udp: Audio Watchdog: no audio data received for 2s, restart required?
2023-01-30 23:20:36.700 INF audioconverter: Closing audioConverter() Input: 1 Channels of 1 16000 SignedInt 16 Output: 2 Channels of 0 48000 SignedInt 16
2023-01-30 23:20:36.704 INF audioconverter: Closing audioConverter() Input: 2 Channels of 0 48000 SignedInt 16 Output: 1 Channels of 1 16000 SignedInt 16
2023-01-30 23:22:53.795 INF udp: udpHandler : sending request for missing packet : “0x8f8”
2023-01-30 23:22:53.996 INF udp: udpHandler : sending request for missing packet : “0x8fa”
2023-01-30 23:23:31.878 INF udp: Closing UDP stream : “192.168.1.24” : 50003
2023-01-30 23:23:31.880 INF udp: Closing UDP stream : “192.168.1.24” : 50002
2023-01-30 23:23:31.880 INF udp: Sending token removal packet
2023-01-30 23:23:31.881 INF udp: Closing UDP stream : “192.168.1.24” : 50001
2023-01-30 23:36:30.179 INF system: Serial Port found: “ttyACM0” Manufacturer: “Icom Inc.” Product ID “IC-705” S/N “IC-705_12004047”
2023-01-30 23:36:30.193 INF serial: Opened port: “/dev/ttyACM0”
2023-01-30 23:36:30.193 INF system: Received CommReady!!
2023-01-30 23:36:30.194 INF system: Delay command interval timing: 75 ms
2023-01-30 23:36:30.195 INF default: Setting rig state for wfmain
2023-01-30 23:36:30.195 INF default: Setting rig state
2023-01-30 23:36:30.197 INF rig: Using incomingCIVAddr: (int): 164 hex: “0xa4”
2023-01-30 23:36:30.197 INF serial: Received rigCapabilities for “IC-705”
2023-01-30 23:36:30.198 INF rig: Have rig ID: decimal: 164
2023-01-30 23:36:30.211 INF rigctld: Got rigcaps for: “IC-705”
2023-01-30 23:36:30.216 INF system: Delay command interval timing: 25 ms

12

Elliot,

I’m sure my setup would make contacts, and I have made contacts with my base staton from the 705 setup, BUT the audio is still glitchy. I wouldn’t have known this except for the fact that I listen to the tx audio on the 705 from the 705’s speaker and I watch the tx signal on the 705 band scope. The glitches can be clearly heard annd are most evident on the “tune” tone from wsjtx. It gets glitchier immediately after band changes (all testing at low power to a dummy load).

Have you listened to your tune tone, then switched bands and listened again? Tried turning the tone on and off a few times? No glitches at all?

What OS is running on your RPI?

Thanks again,
Tom

13

Hi Tom,

I am generally running Linux Mint 20 on a Thinkpad T495. I also run Mint on a variety of other older computers. Audio reports are generally favorable and I have checked, it sounds very good.

Many windows users have had success as well.

You may need to disconnect and try one of the other audio subsystems such as RT Audio. Live streaming audio is tricky, and you may well find that one of the three audio subsystems is a lot better. I know I had clicks on port audio at one time, for example. Launch wfview from a terminal to see the audio system notices (if any).

—E
de W6EL