RPi4 8gb as Wfview server, and PC as client and audio is brilliant. Latency low, rtt low errors none
RPi4 8gb as Wfview server and another RPi4-8g as client audio is very broken, Latency low, rtt low, errors none
I have Opus 1ch for RX and TX, sample rate 8000. Ideas appreciated… thanks Mike G8NXD
I wasn’t able to find any RPI users who had clean TX audio! Have you confirmed that with the RPI as Wfview server and PC as client the TX audio is clean, particularly on WSJTX even after band changes?
In your example with bad audio, how is your RPI connected to the second RPI? In that example, what audio are you sending that is bad? Is it audio in both directions that is affected? What operating system are you running on the second RPI in that example? What does your wfview log for that operation look like? In the bad audio example, what is the connection between the server RPI and the radio, and if that connection is via TCP/IP what is the latency between the server RPI and the radio?
What are you trying to achieve by having an RPI as server and another RPI as client as opposed to operating the server via VNC?
Have you tried a single RPI as wfview server and client with wsjtx on the same RPI and the RPI operated via VNC? What was your audio like in that condition?
IC-7100 via USB to RPi4 server in garage, thence over wired network to:-
RPi4 client in Front room over network to server. Also PC (Win11) and PC (Win10) in front room.
only connecting one client at a time… before you ask
The Win11 and Win10 client PC’s both have good audio on TX and RX with rtt about 4ms, latency about 40ms average, no errors. The Win11 is via cable to the router the Win10 pc is via wi-fi to the router
The RPi4 client via cable to the router, on the same switch as the Win11 PC, rtt, and latency very similar to the Win PC’s. No errors. Very distorted audio on receive, not attempted TX on the RPi4
all clients use opus 1ch for TX and RX and 8000 audio sample rate. Not attenpted WSJTX yet on any client.
I cant really offer much assistance with the RPi client as I have never used an RPi as the client on wfview, what I would suggest though is Opus is optimized for 48K audio sample rate, so there is little benefit in using 8K. In fact, the significant resampling that is going to be required, may actually slow things down.
What does the comparison of the debugging logs in wfview between the good setup and the bad setup look like on the server side?
On the bad setup on the client RPI, how are you playing the audio on the client RPI? Speakers to the audio jack or a separate audio card?
What happens if instead of running wfview to wfview with the 2 RPIs, run wfview on the server as well as murmur and VNC server and then on the client rpi run mumble and VNC? Do you still have audio problems in that configuration? I imagine that setup would get you the same functionality as what you are attempting to run?
I’ll look into the logging. I cannot use VNC because eventually I will be locating the server at a distance on a different network, TightVNC is limited to local network or via TightVNC server to other network, I concider unacceptable intrusion and routing delay. My knowledge of Murmer is very limited and I never got it to run, user error certainly.
Mike, Have you tried the different audio subsystems (QT Audio/RT Audio/PortAudio) on both the server and client? You would need to disconnect from the radio to enable the combobox, try each in turn on both the client and server.
RealVNC will try to dark-pattern you into a subscription to their rendezvous service, but if you always supply address information directly when you connect you don’t need it.
I’ve been using VNC and and off since the good old days when it was invented at the Olivetti lab in the UK.
I am so surprised to hear that----I think I have used it for maybe 3 years and haven’t experienced anything like that. I use the app on an iphone to access the RPIs and I have their IPs in the app. Never recall receiving a solicitation or any choice to pay anything.
In any event, at least the ios version doesn’t have its own audio transportation, so Mike would need murmur/mumble running or something like that.
I have stumbled across a fix for my own audio dropout problem, and I don’t know why it works but it does for me. Perhaps you should give it a try.
I have found that I get audio dropouts UNLESS I have the RPI PulseAudio Volume Control program running----I need not tweak any audio settings, I just need it running. This program is found under sound and video. I don’t remember installing this, so I think it is a standard part of the OS.
I would suggest you have PulseAudio Volume Control running on both the server and client RPIs and see if that makes any difference.
I know this sounds a bit nuts, but it has worked for me, and if I terminate the program the audio dropouts return. I have no explanation for why it works.
73 & let us know if it fixes your problem,
Fascinating! That is tomorrow night’s project…although I am running WSJTX and not fldigi but I guess they are suffering from the same effect!
Why is this necessary at all? And another question, why does the WSJTX/WFVIEW team need the pulseaudio volume running when WSJTX connected by USB to the rig without wfview running does NOT need pulseaudio volume running?
I just updated the audio page for WSJT-X and fldigi. Just a minor update, but I thought screenshots would help. Your config will be a little different though since your loopback devices are named different.
If you want to send us a screenshot that would be great.