I get reports that my audio is bad with Wfview. Switching to RSBA1 or Win4Icom I get excellent reports.
I have an IC7300 in the remote schack with USB connected to the computer. On the remote computer I can run Wfiview or Icom’s remote utility in server mode.
On the local side I have two different computers and an USB headset. With RSBA1 or Win4Icom running as a client, I have no problem with TX audio. But with Wfview it sounds distorted. I have done several AB-tests and switched back and forth between the two different computers and between RSBA1 and Wfview. I have experimented with different sample rates and different codec’s and there is no improvement. The conclusion is clear, the audio is distorted!
And what bugs me the most, is that there is really no one else in this forum experiencing bad audio!
Can I have exactly the same problem with two different computers? And what could it be?
Please listen to the audio and tell me what you think. According to the reporting stations, sometimes it is worse than in the example, barely audible but sometimes it can better. But never 100% clear.
Oh, I was not aloud to upload audio. Here is a link. Hope it works!
Just to confirm, both client and server are windows, correct? 64-bit Windows 10? And both are running version 1.61 of wfview, yes?
Have you tried turning on the audio meter (TxAudio or TxRxAudio) in wfview to verify you are not actually overloading the input level? Try that, see if your speech is a reasonably level going in to wfview.
Next, enable the ALC meter and adjust the “USB” slider in wfview to adjust the USB transmit modulation level for a good ALC reading.
I’m sure you do but I ask anyway; do you disconnect and reconnect every time you change codec and sample rate? If not the new setting is not activated in my experience.
I’ve had similar bad audio and it was related to codecs and sample rate and also which audio system I chose (QT, pulse e.t.c)
My current working settings for TX (with an IC-7300) are sample rate 8000, “LPCM 1ch 16bit” and QT Audio and 250ms TX latency. This is a compromise setting for low bitrate and acceptable audio quality as I run over 4G cellular network as you know.
I’m running 1.60 on both ends on Windows 11. I read the post on not having to update if you hadn’t a specific problem related to something other than audio. But I can try tonight. I doubt Win 11 would be different than Win 10? I could test with a Win 10 machine on the client side. But the server side is really not feasible to change.
TxAudio peaks on -6dB. And ALC stays in the non-red area.
Ulf - SM0NOR
As Björn mentioned, the codec, audio device, audio system, and sample rate cannot be changed during an active connection. wfview might appear to let you change it, but it does not actually change. You need to disconnect from the radio, change the parameter(s), and then re-connect. We’ve been meaning to lock out all the relevant controls but just haven’t remembered to do so.
Please advise me of the parameters you are using:
TX and RX codec
Also please send me your client log, which you can do by pressing Log and then pressing “send to termbin” and then, don’t forget, paste the resulting URL in to your reply on the forum. The URL will already be in the clipboard once you see it on the screen.
Yes, I have. I’m running the same as you. But 16K.
Potentially, you could connect to my remote from your client and that way determine if the problem is on the client or on the server.
DM if that is doable.
With that level of packet loss, you are unlikely to be able to achieve a stable connection to be honest. The client (and server) stamp each packet with a serial number and if a packet is lost, you will receive those messages in the log. That is a physical connectivity issue between the client and server.
Can you describe your connectivity at both the client and server side? Mainly the connection type, whether any wireless LAN or network bridges are in use at either site etc. as some devices are not very good at passing large numbers of UDP packets?
I would absolutely recommend using Opus for both TX and RX audio (with 48K sample rate) as it is massively more efficient and results in much smaller packets. There is practically no benefit in using lower sample rates with Opus though.
OK. Then, it is possible that the weak link is my wifi at the remote station after all. It’s a bit hard to accept as RSBA1 works flawlessly. But I have no knowledge of how efficient respective software is? So, I guess my next course of action is to improve wifi connectivity.
I have switched to Opus now. Still distorted sound.
For the same mode/sample rate, wfview will be pretty-much identical to RSBA1 in this regard. It is possible that RSBA1 might handle poor connections better but in my testing, I have actually found the opposite to be true.
Can you disconnect and switch to PortAudio and let us know if the experience is any better?
To fully test this out, both the client and server will need to be changed to PortAudio. PA is just a different library. Make sure the client side program is completely closed when you change the audio system on the server. Don’t forget to press Save Settings.
I would keep Opus as the codec and the 48k sample rate as well.
When you change to PortAudio, make absolutely sure to check and re-check that your audio devices are properly selected on both the server and client sides. They may have slightly different names.
With PortAudio it works. I tested and had an half-our QSO with another station. The audio reports were good all through the QSO. Still, there seem to be a lot of missing packets issue in the log-file. But perhaps Wfview can stich them better together with PortAudio?
Log file: https://termbin.com/jleuw
ULF - SM0NOR
There’s some mechanisms in wfview that help with missing packets, but it really isn’t ideal. Phil could tell you more about exactly what can be tolerated I seem to think Opus has a little bit extra tolerance due to FEC but I may be incorrect.
Are any of the computers involved using wifi? If you can get one on ethernet it will probably make a lot of improvement.
Thank you for great support!
Yeah. The server uses wifi at my country side cabin/cottage. I’m probably the only one with a wifi router in the neighborhood so the signal from the main house to the schack (20 meters) appeared strong and good. But when seeing all the lost packets I learned that audio demands more. So, the immediate plan is to put up a wifi bridge. Ideally I would dig for a cable, but the ground will be frozen for another month so that has to wait
/Ulf - SM0NOR