We have actually got DSP plugins working with transmit and receive audio. It’s just a matter of putting all the right parts together with a UI, then you’ll see it in wfview. First we wrote it for LADSPA, and then re-wrote it for LV2. I tested it with EQ and compression mostly, but there are noise reduction plugins for LV2 that might be interesting. CPU usage was pretty low, I think a Pi or other modest hardware would handle it fine. One of my favorite compressors, the so-called “Dyson compressor” was written in the 1990s and could handle real-time audio on a P90. So I don’t think a dedicated computer is needed at all.
I am serious that there is a business opportunity for you and your friends to sell a Pi version that does does TX and RX audio EQ AND RX noise reduction. I constantly talk to guys who have some fancy EQ for their TX audio that they paid far too much for. Even a not very computer literate person can plug a USB keyboard and HDMI monitor into a Pi and route their RX and TX audio in and out. I don’t care much about TX audio as the 7610 has plenty of EQ controls. What is missing from every ham transceiver is excellent noise reduction.
Icom have long had excellent noise blanking. I have electric fences on my farm and without NB every two seconds I get an s9+ crack but with NB on it vanishes. The 7610 Noise Reduction is better than my original 756, 756 Pro and even 7600 but still not very helpful with a weak signal. How do I test one of these noise reduction tools you talk about either on Mac or Windows?
It’s just one of many things we have on the roadmap. Things like dual-VFO, dual-waterfall, waterfall overlays, more transceiver controls (including the OEM NR/NB controls), satellite ops, and more, are all taking some priority and moving at a snail’s pace as we’ve all got many other things to do (such as work!).
One of the challenges with the plugins is the user interface for selecting plugins and building up a UI to represent the plugin’s controls. And then you get into saving control presets, chaining plugins together, metering levels, etc etc. It’s a lot of connectivity code making it all work smoothly and predictably. Performance-wise it’s there, it works, and it’s pretty cool. If you’re savvy with linux, you can try it out from the “lv2” branch, but remember, you’ll have to edit the code to select plugins:
I’m not a programmer unfortunately and know nothing about Linux. I do have five programmers who work for me full time who use Linux for all our software that runs on AWS so I could get one of them to do it for me but none of them are into ham radio so I would be paying them to do something they don’t have any interest in or understanding. So I will wait not very patiently for your progress.
I have the same results as what Phil describes – RBSA1 is good, wfview for most radio’s seems to be a bit better. However, it all depends on the latency settings too – the numbers that affect the size of buffers and/or loss of packets.
I decided to have another play with WFview settings. I gradually pushed out RX latency and listened to a QSO for extended periods. When I got out to 300ms I no longer hear dropouts even when I open the wifi dropdown which starts scanning for additional access points. Are you using the radio “prebuffer” setting that I see in RS-BA1? What’s with the “retransmission audio data” check box in RS-BA1?
To test the effectiveness of the 300ms latency I connected my Macbook to my Starlink connection and left the 7610 on my old slow internet which has a static IP. So now I am running WFview remote from my radio by bouncing through Mr Musk’s satellites. The result is now better than RS-BA1. I see from RS-BA1 that the radios only support 8 and 16 bit PCM and 8 bit µ-law so I presume the opus codec only works when using a separate WFView server? If so you might want to add a popup note on the settings screen. I read about opus and listened to some online demos. It is pretty amazing and I see that Opus uses two codecs in parallel, one of which is Silk that Skype uses and I have seen how extremely well that works on very slow speed internet connections to Africa with long ping times and massive jitter. Changing polling interval made no difference at all - does that only work with WFview server as well as I presume the radio just streams continuous unacknowledged UDP packets?
Although there is a WiFi link involved, this is only between the MacBook and the mobile phone. They are next to each other, and there is nothing else sharing the link.
Codec is Opus 1-channel, 4800 bps. Latency is set to 300ms.
Here is a short video showing a stutter, and a complete drop-out for several seconds. The MacBook (client) is in the foreground, and the Pi (server) is in the background. Note that the waterfall continues on the server when the client drops out. Also, it is interesting to note that the waterfall catches up when the client resumes, with no gap.
Although this drop-out is only for a few seconds, I have seen much longer: perhaps 30 seconds. They tend to happen approximately every 3-4 minutes.
Under identical configuration (but with a PC as the server), RS-BA1 does not drop out.
I would definitely suspect that something in the Pi is causing the network to ‘hang’? You could try running a ping on the pi at the same time and see if any lost pings coincide with the stutter.
Also, the log file Log file | wfview can help us with diagnosing this further. Running in debug mode may also help as that generates significantly more logging!
I have the same thing happening with Win 11 connected to an IC-7610. It can be a little annoying. However, this also happens when using the Icom Remote Utility.
I only operate with SSB so my old ears just accept it an normal, similar to a noise burst that cuts a signal for a short moment.
Make absolutely sure that on the Hotspot, there are no other applications running that use cellular data, and that any kind of client-style wifi is turned off. My dad is doing a similar setup with the IC-7610 and he had dropouts every 20 seconds initially. Then every 60, and finally, after he had all the other things disabled on his iPhone hotspot, it was clean and he was able to operate PCM at 48k. I don’t know if that’s your issue, but every little blip in performance can be noticed when you’re running UDP from a live source.
I plugged in my Icom USB RC-28 remote control VFO knob that I use with RS-BA1 but it didn’t work as I expected - I was being rather optimistic. Are there any plans to support that?
I have been working on support for both the RC-28 and Countour Shuttle USB devices and have been making progress (the Shuttle works quite well) this is definitely something that wfview will (eventually) support.
I understand suspecting the Pi, but actually I have also tested using a Windows PC with similar results. However, let’s continue with the Pi and see if that gets anywhere.
The ping suggestion is interesting. I have run three tests today:
In all three cases, there were no interruptions to the ping during a wfview hang.
Today I was monitoring the log file, and noticed that I was getting latency warnings (whilst set at 300ms). I increased to 500ms, and the warnings went away - but it was still hanging occasionally.
I have captured a debug log file today during a hang. In this instance (and the first time I have seen this behaviour) it never recovered! I let it continue for about a minute during the hang, and then closed the server.