I’ve been monitoring this, and measured around 500k up and down when set to 48000 and 8 bit audio. However, it jumps on the transmitting side to over double that sometimes for an unknown reason. Any idea what’s going on? And why is it even transmitting that high to begin with when all it should be doing is receiving information from the server?
I can drop it down on both ends by going to 8000 for a sample rate, but I get frequent audio pops on anything 24000 and below. Is there anything that can be done about that? I haven’t tried different internet paths yet to see if it’s the specific router on the client end causing that.
It really helps if you include as much information as possible when asking a question, wfview version, radio mode, operating system etc. Also units of measurement help (is it 500Kb/s or 500KB/s?)
Audio is full-duplex at all times, so it is always sending audio to the server regardless of the transmit state (this is the design of the Icom protocol, so not much we can do about it), no idea why it would occasionally increase though as the audio is being constantly sent at the same rate. It is possible that is other traffic unrelated to wfview?
We are looking at a half duplex mode, but this will something in the future (if you have a recent version with a Duplex combobox, this doesn’t currently do anything!)
If you are using the wfview server, then I would definitely recommend Opus for audio as it is a MUCH more efficient codec than PCM/uLaw, unfortunately that isn’t available for connections direct to Icom rigs as they only support PCM/uLaw. If not, then 8bit uLaw with 16K sample rate seems to be the sweet-spot for many users.
I switched to 48000 and Opus on the client and it dropped to 160 RX/88 TX Kbps as seen in Windows 10 Task Manager under Performance. IC-7300 via USB, 115k2 CI-V, 7.200 MHz LSB receive, waterfall as slow as it goes, latency set to defaults, 30/1 latest version of WFView. Not seeing it jumping to double the TX data rate now either.
When it would jump to double the TX rate, restarting WFView would usually restore it to normal.
The frequency “knob” is just way too tiny even in full screen on a laptop with touchpad. I’d prefer a larger knob or a pop-out knob, up-down “pushbutton thumbwheels” like in SDR#, or even a slider. Something to pass on to whoever’s working on things…
I don’t really know anybody who uses the tuning knob, most users use their mouse scroll wheel (or an external knob). I will pass your comments on to the rest of the team though.
