Method of radio connectivity (USB, WiFi, Ethernet, etc): USB
Did you check the FAQ and read the manual? Yes
I have wfview set up on both the server computer (Windows 10) and the client (remote) computer (Linux Mint). Almost everything is working – I can control radio settings, tuning, etc. and have audio output at the remote computer). The one thing not working properly is the microphone at the remote computer. The microphone controls (Sound settings) show the microphone is picking up sounds, and in fact echoes them to the speaker output (not desired), but this microphone input is not getting to the radio during transmit. The power output meter on the radio doesn’t indicate any change when speaking into the mic with Transmit active.
No doubt this is some combination of wfview, Windows 10 sounds, and/or Mint sounds settings not being correct. But at this point I’m tried a wide variety of combinations, and am overwhelmed – there are 54 devices to chose from in the wfview Input selection alone, not considering OS sound settings. The number of possible combinations to try is in the thousands. I’m hoping someone may be able to suggest some troubleshooting steps I haven’t yet tried.
So, again, many things are working so my basic connection is OK between radio, server wfview, and client wfview. I get reception audio from the radio just fine to the remove wfview. The microphone is working and indicates a strong pickup in the Mint (client) sound settings. I assume the Audio Input device selection in the client wfview should be the same as the Audio Output device selection. I’m using Opus 1ch for the codecs. The microphone input is echoed in the speaker output at the client for some reason (this may be a clue). I enabled the TxAUdio UI and that shows no input/no movement when speaking into the mic.
Messing with wfview some more, I found an input device that results in movement of the TxAudio meter. However, unfortunately it also blacks out my remote client monitor! This monitor baclout occurs whether transmitting or not – as soon I connect the remote instance of wfview to the server instance, the monitor goes dark. Logging into the server PC via another computer and shutting down wfview on the server PC restores my client monitor to normal.
Of course everyone will say RFI, but I really doubt it in this case. First, with a different setting of the Input device it doesn’t happen (of course there is no transmit audio either with this setting). Second, it occurs even when not transmitting (putting out RF). Third, I have ferrites on everything.
Audio:
Device-1: Intel driver: snd_hda_intel
Device-2: C-Media USB Audio Device type: USB
driver: hid-generic,snd-usb-audio,usbhid
Device-3: ARC Camera type: USB driver: snd-usb-audio,uvcvideo
Device-4: Zoran Personal Media Division (Nogatech) USB Audio and HID
type: USB driver: snd-usb-audio
Sound Server-1: ALSA v: k6.8.0-48-generic running: yes
Sound Server-2: PulseAudio v: 15.99.1 running: yes
Sound Server-3: PipeWire v: 0.3.48 running: yes
This is a subset (less than half) of the devices listed in wfview’s Audio input and Audio Output dropdown lists.
I’ve tried a large number of combinations in those dropdowns, right now I have it set to “default” in both. Some combinations result in no Transmit audio, but Receive audio and the monitor is fine. Other combinations results in both Receive and Transmit audio (with an echo), but the monitor goes black.
If I unplug my USB headphones with microphone (the intended target for Receive and Transmit audio), Device 2 (C-Media USB Audio Device type: USB) disappears, then re-appears when plugged back in. In the Mint Sound Settings window, this device appears to be called “Speakers USB Audio Device”. Selecting that in Mint Sound Settings results in sound output through the headphones.
OK, OP here again. Fiddling some more I now have Receive and Transmit audio both showing on the wfview View window, and my monitor doesn’t go dark! But now the problems are:
When I speak into the microphone during Tx, I hear myself in a different set of speakers (not the headphone speakers). Apparently the mic audio is still not right – the second set of speakers shouldn’t be in use at all for radio purposes. (They are used for playing music off-radio.)
Despite seeing the Transmit audio meter move up to near 100% when speaking, no power goes out over the airwaves. The ALC meter in wfview shows 0 ALC. When not using wfview, and setting the IC-7300 to MIC input then using the desktop microphone (plugged directly into the radio), I get full expected power out when transmitting. The only radio setting being changed when switching to wfview is the Modulation Input from MIC to USB.
The most likely cause is that you have the incorrect audio settings on the ‘server’ computer. Did you follow the manual (exactly) Remote Operation (server) | wfview specifically the bit about audio input/output devices (in the Radio Server tab)
Phil, assuming you are responding to my latest message (before yours) – should the Radio Server audio/input devices on the SERVER wfview instance be the same as on the CLIENT wfview instance? Or should the SERVER instance settings be whatever USB device/cable is used between the server computer and the radio?
The server is connected to the radio, so the audio devices must be the radio USB Codec ones (as it shows in the manual). This is configured only on the Radio Server tab, the audio devices in the Radio Access tab are not used at all when the radio is connected by USB.
I also confirmed the Radio Server tab audio settings. there are only three choices in those dropdowns, and they are set to the only one that makes any sense - USB Audio Codec.
Those settings look OK, but I would need to see both logs from when the client is actually connecting to the server, as it is possibly a sample rate issue. Also make sure that the USB Audio Codec devices (both speaker and microphone) aren’t muted in Windows on the server machine and are set at a reasonable level.
It is fixed. The USB device was muted on the server PC, so your last comment pointed me in that direction and once changed it all began to work.
Thanks for your help. I would suggest adding this small but important point to the docs. It may sound obvious to most, but because Receive and Transmit audio were working it escaped my attention.