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 in the same boat. Not sure how to alleviate this problem. It’s frustrating for sure!
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.
Absolutely, go ahead with sharing any information relevant to ham radio.
Honestly, I haven’t even bothered with the alerts yet. I’m still trying to understand all of the other functions of the software and not accidentally change something that’ll make things worse. 
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.
Following up on my earlier post, here’s a workaround:
Make these additions to /etc/asound.conf or ~/.asoundrc. If neither of those files exist, create /etc/asound.conf (need root privileges) and add these lines:
pcm_slave.digirig {
pcm {
type hw
card Device
}
period_time 0
buffer_size 8192
}
pcm.digirig-dmix {
type dmix
ipc_key 2023041901
slave "digirig"
bindings.0 0
}
pcm.digirig-dsnoop {
type dsnoop
ipc_key 2023041902
slave "digirig"
bindings.0 0
}
pcm.digirig-rx {
type plug
slave.pcm "digirig-dsnoop"
hint.description "digirig RX audio plug"
}
pcm.digirig-tx {
type plug
slave.pcm "digirig-dmix"
hint.description "digirig TX audio plug"
}
Save the file, then restart Fldigi, You should now be able to select digirig-rx and digirig-tx in the Capture and Playback dropdowns respectively in Fldigi Configure > Soundcard > Devices.
Wow!!! Thank you!!
Thanks for the help!
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:
ATTRS{id}=="Device", ENV{PULSE_IGNORE}="1"
Save the file. You can either reboot at this point or do the following steps:
systemctl --user stop pulseaudio.socket`
systemctl --user stop pulseaudio.service`
sudo udevadm control --reload
Plug the DigiRig back in to the Pi
Start PulseAudio:
systemctl --user start pulseaudio
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.
AG7GN,
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.
This is great ! I have been having the same problem for several weeks and was going crazy trying to figure out a fix. Here’s my post earlier on the same topic:
https://forum.digirig.net/t/fldigi-configuration-for-digirig-on-raspberry-pi-4/1511
Drew pointed me to this topic…
AG7GN says to make the changes to /etc/asound.conf or /.asoundrc.
I have both files, I’m guessing that /etc/asound.conf is preferred. AG7GN: is that correct ?
Thanks again,
Rob, KK6JNI
~/.asoundrc takes precedent over /etc/asound.conf when both exist. ~/.asoundrc applies only to the current user. If you already have both, it’s probably best to put it in ~/.asoundrc.
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.
Sorry, no. I have not seen this behavior. Have you posted this on Linuxham? Lots of Pi users on that forum and Dave W1HKJ, the Fldigi developer, monitors it too.
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.
I use hdmi on some and the headset jack on others. I took some screen shots and I’ll post what I’m doing now in a separate thread. I’m using the notifications menu for custom audio alerts.
