Before and after photos attached. I am able to select the USB PnP Sound Device in Fldigi on a Raspberry Pi 4 before running update/upgrade, but after updating the Pi the Digirig is unavailable to select.
The system does detect the Digirig otherwise, but fldigi doesnt see it. Removing Pulseaudio doesnt help. Forcing the sound card order doesnt help. I can simply continue using the Pi without updates, but that seems unwise. Does anyone have any ideas?
I’m so glad I’m not the only one! The only two things I have found that work with my setup are to either not update the Pi model 4, or use instead a Pi model 2 or 3.
I was able to get the updated Pi 4 to work with the Digirig by just selecting “default”, and ensuring that the USB PnP device was check marked on the sound menu of the pi (on the task bar), but it doesnt appear possible to then select a separate sound output for your Fldigi audio notifications, which takes a lot of the fun out of digital comms.
Speaking of those, have you figured out how to set up audio notifications yet? It took me days of trial and error but I finally figured out how to set up ring tones for Fldigi.
Denis- it’s not precisely digirig related, but do you mind if I make a post on here for how to set up audio notifications? The available info elsewhere online is limited and very difficult to follow.
This problem is not related just to the DigiRig. Other sound devices (SignaLink, FePi sound card hat for example) are also not listed by Fldigi after the update. My experimentation indicates that with the latest 64 bit version of Raspberry Pi OS on a 4B, the hardware devices do appear as expected in Fldigi. They also appear as expected on a Pi 3B with latest OS updates. The problem seems to be specifically related to 32 bit Raspberry Pi OS on Pi 4B.
You’re welcome. Here’s another tip: I prefer not to have my sound cards (USB or hats) that are used with ham radio apps be part of PulseAudio (they will be by default). You can exclude them by creating a udev rule file in /etc/udev/rules.d/. I call my file /etc/udev/rules.d/89-pulseaudio-digirig.rules. The number at the beginning of the file name determines the order in which the rules in that folder are applied. The content of that file (need root privileges to create it) is:
Save the file. You can either reboot at this point or do the following steps:
I’d like to confirm that making the additions to the asound.conf file worked perfectly. Took me a couple tries, but that was due to my total lack of experience with linux terminal language. Thanks again! Now I’m gonna tackle tyour PulseAudio tip.
Thank you for sharing this fix with us. After writing the asound.conf file, I was able to select the Digirig! Unfortunately, it then broke my audio alerts that I pipe out to a monitor with HDMI. So I uncoupled it from Pulseaudio like you described, and then Fldigi broke entirely
I flashed the card with 64 bit Raspberry Pi OS, but then could get only extremely low volume audio through HDMI no matter what I changed in /boot/config.txt. I was able to get audio from the AV jack, but there is so much electrical interference at this comms terminal (in a vehicle) that the audio sounded like trash.
So, for now I suppose I’m headed back to the 32 bit OS without the update, and I’ll just routinely leave it disconnected from the internet. I suppose I could just as easily use a Pi 3. For what I’m doing, there is no noticeable difference in performance between the Pi 3 and 4. I even have a Pi 2 in my system that - at this point - is my most reliable comms terminal.
I really appreciate your time. Even though it didn’t work out for what I’m trying to do, I’m glad this info is now posted online somewhere for people to find.
AG7GN - Do you have any insight as to why fldigi locks up after about 24 hour uptime on some RPi’s, but not others? Transmission bogs down, and only dead air is transmitted, resolving with either a reboot or simply closing and reopening fldigi. I’ve got one Pi 2 that can run forever. The rest have to be restarted with crontab every 12 hours to keep things fresh and running reliably. I haven’t yet found consistency with the fldigi versions, pi versions, etc.
Thanks. I wasn’t aware of Linuxham but I’ll check out that group.
After some more troubleshooting, I have figured out some consistency with these errors.
On one system, I had the transceiver only a few cm away from the RPi. Way too close! After moving the two about 20 cm apart, the weird inconsistent software issues resolved.
On the other comms terminals that lock up after a day or so of uptime, my new hypothesis is that this is temperature related, as I was just using plastic cases and not fans. It appears that the software issues begin when the CPU temp rises to the mid 70s. I understand that the RPi CPU begins throttling performance at a certain temp around that range, and I hypothesize that this causes issues with FLDIGI that then requires a restart. I am adding fan cases and I will see if this begins to resolve. But I’m probably wrong!
@drew_rinella I don’t have a monitor attached to my Pi so I don’t use HDMI audio, but I do use Fldigi alerts with the alert sounds sent to speakers attached to the Pi’s onboard speaker jack. The onboard audio system is used by pulseaudio, but as I mentioned earlier I have excluded the DigiRig from pulsaudio. Here is my Fldigi devices and alerts configuration. Note the alert destination is sysdefault and that you can adjust the alert volume in the Alerts pane. I had to make some adjustments there as well as the Pi’s master volume control to set the right level for the alerts.