Network issues (just started)

Bugs
1

Brief summary of problem (put in title as well):
Network (wfview client/server) no longer sends audio
Radio Model: ICOM 7300
Connectivity (USB/Ethernet/Wifi/Other): USB to Radio, WIFi/Ethernet between client/server
Operating System: Linux Neon 64-bit x86 on both sides
wfview version (press “About”): 2.03 (but problem surfaced when using “creator-widgets” branch
Checked the wfview manual (Y/N): Y
Checked the wfview FAQ (Y/N): Y
Tried to google it (Y/N/NA): Y

What I did:
All was working on both the last release and the “creator-widgets” branch. However, I had an update to the Linux systems and suddenly I had no audio coming from the remote. I decided to grab 2.03 with no success. The remote system never shows up in pulse audio (I would think its input/output to the radio would connect via pulse, especially when set to do so). Of course, the system is running pipewire and the pulse interface to it, but still. The log on the server seems ok. On the client side I get:
repeated warnings about QAudioSink(pulseaudio) pa_stream_write invalid argument

It is tricky because, in general, disconnecting the radio and opening settings causes a crash with the message:
Fatal glibc error: pthread_mutex_lock.c:460 (__pthread_mutex_lock_full): assertion failed: robust || (oldval & FUTEX_OWNER_DIED) == 0

So getting it to take different values is dicey.

In addition, the latency numbers when connected seem crazy ranging from normally small to 65535 (0xFFFF).

I have tried QTaudio, Portaudio and on the other side Pulse and direct alsa strings. I have tried various codecs, too.

Expected behavior:
Sound flowing to client computer

Observed behavior:
No sound flowing to client computer

UPDATE:
I changed the IP address to some nonsense which allowed me to get in without crashing and set the audio devices again (they must have changed). Then IP address back. Audio is now fine.

However, now any time the hamlib client (JTDX) tries to change the VFO there is a hamlib error :frowning: More troubleshooting to follow.

UPDATE #2:
This seems to be the T command issue discussed elsewhere. I kept the server at 2.03 and reverted the client back to 2.01 and all is well…

2

Nice, thank you for posting.

Indeed the T command seem to have some variants that we had not seen before; we will update wfview to accommodate it. Icom radios cannot transmit on VFO-B ever anyway, so we had not encountered this before.

Old settings are really quite the annoyance. We may add a “--reset” flag for wfview to zap its preferences on start.

Let us know if you have further issues.

–E
de W6EL

Edit: Ok, some Icom radios do allow VFOB for TX, but the 7610 does not, transmit is always on the main band (despite the red TX icon on the screen which makes you think maybe they considered allowing selection of the other VFO for TX…)

3

It seems that a (fairly) recent version of Hamlib has added the format to the set_ptt/T command with a seemingly optional VFO argument.

4

Yes and if you build JTDX they ask you to use an updated version of hamlib so that makes sense.

5

What’s strange, though, is the old version seemed to be OK so is this a regression?

6

Hi Al,

Our custom hamlib rigctld implementation is quite different than it was in prior versions. Now the command is read completely and not recognized; before we probably recognized the capital T and just keyed up (ignoring the VFO text). The current version of wfview also utilizes caching for more efficient use of the radio’s CI-V bandwidth and rapid "agreement’ between the rigctld clients, the UI, the radio, virtual serial ports, and so on.

To me, it’s not a regression so much as it is an odd coincidence that it worked at first! This new PTT command was not known to us with the prior version either.

–E
de W6EL

7

Got it. I haven’t dug into the code yet, but I did just clone it and open it about 3 minutes ago.