Also, Fred, can you share with us the latest log file for wfview from the /tmp directory? It may shed some light. Client and server please.
Thanks,
—E
Entire log files or clear them, attempt a run then copy just those?
Ideally log files which exhibit the issue only. One server, one client.
You can also add the “-d” flag to wfview for a bit more debug output.
—E
de W6EL
Fresh run this morning. Server and Client systems tagged appropriately.
Looking at that, both client and server are crashing due to invalid audio devices:
Both have a line like this, note the “Input: 1 channels of 0 0 Unknown -1” this means that it is unable to determine the number of channels/format of the device. While it shouldn’t crash, this will not work!
2024-10-08 10:52:02.880 INF audioconverter: Starting audioConverter() Input: 1 Channels of 0 0 Unknown -1 Output: 2 Channels of 0 48000 SignedInt 16
Make sure that you have valid audio devices configured on the server tab (on the server) and on the radio tab on the client.
Will check - but as I recall I used the same setup for 1.65 and it works.
I’ll let you know shortly.
wfview-20241008121958.log (15.0 KB)
This is the log from the server. Burr-Brown codec (indicated) is the IC-7200’s internal sound card. I set the client up to use a Bluetooth headset and forced the selection - when it connects, only the server side crashes now. I can cancel the connection at the client, restart the server and duplicate the condition.
2024-10-08 12:20:12.471 INF audioconverter: Starting audioConverter() Input: 2 Channels of 0 48000 SignedInt 16 Output: 1 Channels of 0 0 Unknown -1
2024-10-08 12:20:12.472 INF audioconverter: Starting audioConverter() Input: 1 Channels of 0 0 Unknown -1 Output: 2 Channels of 0 48000 SignedInt 16
There is still an unknown audio device involved here. Please carefully review your server audio settings and try again.
The log file is your friend, check carefully and you’ll usually see something about what’s happening under the hood.
–E
de W6EL
I’d like to hear from others who have successfully gotten the IC-7200 (or other Icom rigs which feature an embedded sound card) working in client-server mode.
The 7200’s hardware devices show up as Burr-Brown codecs. These work properly with other multimode software - either being natively detected, or via Pulse Audio. If I select them directly via QT Audio, no dice. Nor does selecting Port Audio and specifying the “pulse” device - and I’ve tried other combinations including oss, etc.
RT Audio gives me system-embedded Intel codecs and not the Burr-Brown USB connected devices.
Seriously scratching my head on this one. I deprecated both client and server to 1.65 and got the same results.
Hi Fred,
Your log file shows both the input and output devices are listed for the USB Burr Brown device (along with other devices).
I don’t know why wfview is not using this device. I do see that it says the device is selected:
2024-10-08 12:20:12.471 INF audio: Output audio handler starting: "alsa_output.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.iec958-stereo"
2024-10-08 12:20:12.471 INF audio: Input audio handler starting: "alsa_input.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo"
I wonder if maybe this is caused by having selected an audio device under “Radio Access”? Can you check under Radio Access and verify that there is NOT an audio device selected on your server? If there is one, you may need to change it to something innocuous and unrelated to the radio, save settings, and relaunch.
–E
de W6EL
Tried various iterations of audio configs…QT Audio, Port Audio, etc. When radio access is set to “serial”, there’s no way to directly manage the audio devices. If I set it to “network” and change them then reset to “serial”, the audio system that’s defined on the “server settings” propagates into those fields automatically. This is in 1.94, by the way. I can regress the installation and try 1.65 on both sides if this helps.
wfview-20241010113009.log (13.2 KB)
Tried 1.65 with QT Audio again. Burr Brown codec on server side and Bluetooth headset on the client. Still crashes.
Attached log is a run of the server where I specified the onboard audio devices. No “unknown” this time but a different error immediately prior to the crash.
Both 1.65 client and server report an Invalid Argument when starting the Opus decoder. Not getting the “Unknown device” error with this config, however.
Edit:
More tests:
Built 1.94 for each side, specified either Burr-Brown codecs under QT Audio or pulse under Port Audio (server side). Client is always set to use its Bluetooth audio device (“bluez sink”) in HFP mode. LCM 1ch 16 bit set for the RX and TX codec on both client and server.
No “unknown” device faults but a crash occurs on both side as soon as the input handlers attempt to start. Attached is the log file from the server after a run with Port Audio selected. Behavior is the same (log file wise) with QT Audio selected.
wfview-20241010120126.log (18.1 KB)
That’s because those audio devices aren’t used AT ALL when using a USB radio. Only the ones on the Server tab are used.
I haven’t seen the Opus codec error before, does it work without Opus?
Phil,
My comments about server vs radio access audio settings were based on Elliott’s commentary here:
[NR] and [NB] light in wfview panel - #31 by eliggett (Hopefully the link copied correctly).
As far as Opus goes:
Makes no difference if I select it or the other tx/rx codec I mentioned a couple posts prior WRT crash. But the other codecs don’t throw an initialization error (as my attached logs will show).
Success.
Here’s how I got it working:
- Full Duplex must be enabled (Half Duplex causes a crash, regardless of codec selected)
- Codecs which give the best latency figures are LPCM 2ch 16bit (RX) and 1ch 16bit (TX)
- Sampling rate - 16000
- RX/TX Latency - ~100 slider position
- My headset is Bluetooth. It must be set as HFP and source/sink selected properly in the Audio In/Out drop-downs else dropouts will occur
I have an RC-28 and Bluetooth mouse connected to the client tablet, and all works FB at this point. The updated interface for the 7200 is a welcomed feature-add.
Ah, 1/2 duplex very likely doesn’t work, it was an attempt to reduce network bandwidth, but breaks compatibility with the Icom server, which is always full duplex. I will probably remove it.
Glad you got it working
Phil