In previous post I documented the difficulty I was having getting the snd_aloop approach, as given in the user guide, to work on my new raspberry pi 400.
I finally figured out what was going on.
Came across a blog from Raspberry Pi folks posted early 2021 explaining that they had switched from ALSA sound system to PulseAudio, with a few ALSA plug-ins to maintain some compatibility.
Well, snd-aloop is just not supported - the underlying code is just not there.
Instead, you can use the pulseaudio equivalent.
Here is the user-level script I run before firing up wfview and/or wsjtx:
The pulseaudio command starts the pulseaudio server.
The PulseAudio Commands (pacmd) each create an output device with the given name,
together with a corresponding input device (the loop back) called [the given name].monitor
So, for the wfview audio output device, I use MySinkA
and for the audio input device I use MySinkB.monitor
Correspondingly, for wsjtx audio out I use MySinkB
and for audio in I use MySinkA.monitor
No more difficult than the snd_aloop stuff, and it works like a charm.
B.T.W. system does not want pulseaudio server to run as root, so I don’t.
Linux version 5.10.60-v7l+ (dom@buildbot) (arm-linux-gnueabihf-gcc-8 (Ubuntu/Linaro 8.4.0-3ubuntu1) 8.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #1449 SMP Wed Aug 25 15:00:44 BST 2021
Thank you! This was so simple & it works! I tried all that other nonsense to no avail. The only quirk I had was the virtual cables had to be reversed from your description. Don’t ask me why but they didn’t work the other way around. So, I use B & A monitor in WFView and the opposite in JS8Call. Works like a charm. Thanks again!
Unfortunately this only is visible for me when running Qt audio as the audio system in wFview, and it would appear Qt audio may be why I am getting audio problems. The setup is an RPI over wifi direct to an IC-705. I believe Qt audio may have the wrong buffer size (for wifi udp audio streaming to a 705) when setup by wFview.
I would like to try PortAudio or RT Audio, but the official wFview virtual audio cables no longer work (RPI OS does not support them) and this great system you came up with is only visible to Qt Audio and not PortAudio or RT Audio.
Any idea how to easily setup vitrual audio cables that are compatible with all three systems? or at least one of the other two?
Do PortAudio and RT Audio work otherwise, just without the pulseaudio loopback working?
If you launch wfview from a terminal, using qt audio and the pulseaudio loopback, do you see anything in the terminal? Sometimes the various audio systems will have some debug output here.
Do you get different behavior if you open a program like wsjt-x, which uses the pulseaudio loopback first, and then open wfview? Some of these programs will set various parameters with the loopback and they often prefer to have their say before wfview is opened.
Hard to know if Port Audio and RT Audio are working otherwise…how exactly would I test that? They both appear to produce a valid waterfall but how would I send wfview audio to transmit without cables?
When I launch wfview from a terminal with the debug option using qt audio and pulseaudio loopback there is only this:
pi@raspberrypi:~ $ wfview -d
QMetaObject::connectSlotsByName: No matching signal for on_serialDeviceListCombo_textActivated(QString)
Does this reveal anything?
Regardless of if wsjt-x is opened first the behavior is the same.
I do get differently messed up tx audio with wfview 1.6 vs 1.58 1.6 is normal sounding audio with occasional muting whereas 1.58 would not have as clean a tone…so there is a slight improvement going to 1.6.
I setup another SD card with Bullseye (the latest RPI operating system) and experienced similar audio. My regular RPI is running Buster.
To help verify the source of the problems today I hooked my RPI via ethernet to my local network which was connected to my IC-7610 via ethernet and experienced the same audio glitches I am experiencing with the IC-705 connected via wifi to the RPI’s hotspot…so whatever is happening is not rig or connection method specific and is not RPI operating system specific. Firmware on the RPI is fully updated.
I really need to figure out how to try RT Audio or PortAudio systems on wfview…
The WSJTX tuning tone produces far more glitches far more often than regular FT-8 QSO transmissions. Keep in mind the rig is on low power to a dummy load—this is not an RF problem. So whatever the audio problem is, it is really brought forward with a tuning tone from wsjtx.
What I meant by trying RT and PA was to use a speaker on your Pi and see if the audio sounds good. I think the Pi has analog audio that you can try. It lacks an input, but at least you could see how the receive audio is. If those systems don’t show any speakers available, then never mind :).
The message you reported seeing in the terminal is not relevant, it’s a little thing that has to do with serial ports. You saw no other output during your audio glitching, correct?
Can you share your wfview log file with us? Press “Log” in wfview, and then press “Send to termbin”. Wait a second or two and you will be given a URL that you can share with us here.
So far it seems like the audio system on the Pi is just not happy with your application. I have not tried wfview on a pi in quite some time, although it did work well on the Quadra Inovato, which is currently running wfview as a server on my dad’s IC-7300 (which he accesses using his MacBook with wfview). The Qt Audio system is designed to be flexible and to adapt to different audio systems, so it does not surprise me that it is the only one working with your particular situation.
So here is a wfview log of the RPI connected by ethernet to the home LAN and the 7610 connected by ethernet to the home LAN. wfview was running Qt audio ulaw 1 channel 8 bit for tx and receive at 48000 sample rate. A sample rate of 8000 produced the same result. It would appear from WSJTX decodes that receive audio was fine, but transmit audio had the same problems (TX audio muting/dropouts) exhibited in the mobile configuration (RPI as hotspot and 705 connected over wifi to RPI). In addition, as was the case with wfview 1.58 there was a buzz/distortion on the tx audio. Previously in my testing with 1.6 I did not notice a buzz but that could be just me. see the 7610 all lan/ethernet connected log at https://termbin.com/voe4s
I repeated the test with the same RPI now running as a hotspot and the IC-705 connected to it via wifi (705 running on internal battery) and received the same audio. see the 705 wifi log at https://termbin.com/kk3g – note I had to disconnect the 705 “KillHotspot” to connect to the net to create the log and that is the disconnect listed in the log.
The above testing was performed with wfview starting up first. I repeated the testing starting up wsjtx first, then the cables, then wfview and I received the same results.
At least to me this does not seem to be a rig specific or connection method specific problem. Where do I go from here?
I’ll check it out, Tom, but what appears to be going on is that the Pi you have uses an audio configuration that we have never tested with before. That is the common denominator here.
With my IC-7610 and IC-9700, I have not had any issues like this, and we’re both using the same version(s) of wfview and also both using linux.
I’ll think it over and see if I can come up with anything to try out.