Audio Configuration - Server - Raspberry Pi

Server: Raspberry Pi 3B± Bullseye
wfview: v1.65
Remote: Windows 10 Pro
wfview: v1.65
Radio: IC7300
Connection: USB

After a number of years, I have lost audio connection from Remote to Server. On Server end I ran PortAudio and alsa-brown… for both TX and RX. I no longer have that option on the server end, which I can access with Windows Remote Desktop. I can control the radio through the Server via Remote Desktop.
Log file: [https://termbin.com/9o6g] (https://termbin.com/9o6g)
This started after a remote reboot of the server (software shutdown, OS shutdown (sudo shutdown) then power-off, then power-on)
Suggestions -

TIA
Michael - KG5UMH

I have had this issue before with the IC7300, unfortunately a complete power-down of the 7300 is the only thing I have found that fixes it. I suspect that the USB Controller within the radio crashes?

Thanks Phil, I will give that a try and let you know what happens.

KG5UMH
Michael

Phil,
Removed power (remotely) from the 7300 for 20 minutes. Restored Power to it. Checked the Server end (Raspberry Pi) and the Alsa Brown… sound option still does not appear.
Think I am going to try and remotely reload wfview 1.65 (if still available) on the Server Raspberry Pi and see what happens.
I won’t physically be at the Server location for another two months.

You can check independently from wfview if the radio is visible from the OS.

In a terminal.

Check for sound devices:

aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: PCH [HDA Intel PCH], device 0: ALC262 Analog [ALC262 Analog] (motherboard sound device)
  Subdevices: 0/1
  Subdevice #0: subdevice #0
card 1: CODEC [USB Audio CODEC], device 0: USB Audio [USB Audio] (This is the Icom device)
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Check for serial port:

ls -l /dev/ttyUSB*
ls -lR /dev/serial

This may help if you’re not sure about the device showing up.

–E
de W6EL

Elliott,
Thanks for the response -
Situation has changed some - as previously stated I had been running PortAudio and the alsa brown… audio codec. then suddenly the alsa-Brown… option disappeared.
After trying Phil’s suggestions to no avail, I updated the OS (still Bullseye) on the Raspberry Pi Server. I then installed v2.03 on the Server (I like the look). While putting in the setting, I found that if PortAudio was chosen, I did not have the option for alsa-brown. However, if I chose QtAudio, I did have the alsa-brown option.
From the Server end -(connecting to the Server with Remote Desktop) I have full control of the radio.
I tried to connect from the remote location with wfview v1.65 and could not connect. Nothing to indicate a connection.
I then installed wfview v2.03 on the remote and attempted to connect to the wfview Server with that. Still no connection. Have rebooted several times, (both client and server) verified IP addresses, user names and passwords and I still have no connection. I have a laptop with wfview v1.65 installed I plan to try that on a different outbound Network to see if that works.

Good product, used it for last three years remotely and never had an issue -

Will keep you posted.

Thanks

On your server, run the commands I mentioned and post the output. This will verify if the radio is seen by the OS properly. It can’t hurt to check!

Provide us with a server log and a client log. How to send a logfile | wfview

Audio devices will have different names under different audio systems. I can’t tell you exactly what they will be so you’ll have to look carefully. The server log will show some more details about the audio devices.

–E
de W6EL

Server log: https://termbin.com/zapu
Client Log: https://termbin.com/fk0s
Other requested information:
**** List of PLAYBACK Hardware Devices ****
card 0: Headphones [bcm2835 Headphones], device 0: bcm2835 Headphones [bcm2835 Headphones]
Subdevices: 8/8
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
Subdevice #3: subdevice #3
Subdevice #4: subdevice #4
Subdevice #5: subdevice #5
Subdevice #6: subdevice #6
Subdevice #7: subdevice #7
card 1: vc4hdmi [vc4-hdmi], device 0: MAI PCM i2s-hifi-0 [MAI PCM i2s-hifi-0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 2: CODEC [USB Audio CODEC], device 0: USB Audio [USB Audio]
Subdevices: 1/1
Subdevice #0: subdevice #0

$ ls -l /dev/ttyUSB*
crw-rw---- 1 root dialout 188, 0 Jan 30 14:25 /dev/ttyUSB0

$ ls -lR /dev/serial
/dev/serial:
total 0
drwxr-xr-x 2 root root 60 Jan 30 14:22 by-id
drwxr-xr-x 2 root root 60 Jan 30 14:22 by-path

/dev/serial/by-id:
total 0
lrwxrwxrwx 1 root root 13 Jan 30 14:22 usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_IC-7300_02016696-if00-port0 → …/…/ttyUSB0

/dev/serial/by-path:
total 0
lrwxrwxrwx 1 root root 13 Jan 30 14:22 platform-3f980000.usb-usb-0:1.1.2.1:1.0-port0 → …/…/ttyUSB0

Thanks

1 Like

First major issue is this line:

2025-01-30 14:23:10.398 CRT udp: **** Unable to bind to UDP Control port 50001 Cannot continue! ****

I believe this means something else was using that port. Or perhaps you accidentally had two copies of wfview running at the same time. Are you using the cursed “anydesk” software by chance?

–E
de W6EL

Elliott,
Using MS Remote Desktop. Uses a different port range.

KG5UMH
Michael

You may need to use netstat to see what is listening on that port.

I also note that you are using the “default” audio device, which is probably fine but worth checking once we get past the connection issue.

–E
de W6EL

the command is:

netstat -ln -u

And then look for anything on 50000-50003
–E
de W6EL

Elliott,
This from the Server end -

This is Server side with wfview running and connected to the radio

Elliott,

After sending the screenshot, I opened wfview on the remote computer V2.03 and connected immediately with good receive audio. I went to the setting screen, disconnected from the radio (opus 1ch, Qtaudio, went to conect and cannot connect to the Server.
I have gremlins somewhere.

Sorry the information is coming in snippets -
I connected to the Server via Remote Desktop. I found that the wfview program was closed. I restarted wfview, disconnected from the server. On the Remote, I launched wfview v2.03 and low and behold I connected to the Server immediately - again good receive audio.

Well, I suppose that is good news really, despite the gremlins!

If you continue to encounter the issue, check the logs on both server and client side while the connection is failing, maybe we can figure something out.

–E
de W6EL