Running on Fedora 43 on an Intel i5-12600k machine, using an RTL-SDR.com v4 dongle, using the 0.3.0-x86_64-full-20250408-112743Z AppImage.
I have the RTL2832U device selected in the source selection window using SoapySDR.
The sample processing rate seems to top out at 192ksps regardless of what sample rate is selected, causing the audio preview to cut in and out constantly. There is no CPU bottleneck as the CPU usage is under 10%.
I get this output on startup:
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
SigDigger-0.3.0-x86_64-full-20250408-112743Z.AppImage: locale en_CA not found, using English as default
shm_open: No such file or directory
[ERROR] sdrplay_api_Open() Error: sdrplay_api_Fail
[ERROR] Please check the sdrplay_api service to make sure it is up. If it is up, please restart it.
[INFO] [UHD] linux; GNU C++ version 9.2.1 20200304; Boost_107100; UHD_3.15.0.0-2build5
Found Rafael Micro R828D tuner
[ERROR] SoapySDR::Device::enumerate(sdrplay) sdrplay_api_Open() failed
Found Rafael Micro R828D tuner
From extracting the AppImage, it seems like it is trying to read audio from /dev/snd/pcmC0D0c for some reason? If I use bwrap to disable it from accessing /dev/snd then it speeds up marginally, but only to about 384 ksps. I have no idea what it is doing, but it seems like it is blocking on something it shouldn't be when trying to process the input data?
Running on Fedora 43 on an Intel i5-12600k machine, using an RTL-SDR.com v4 dongle, using the 0.3.0-x86_64-full-20250408-112743Z AppImage.
I have the RTL2832U device selected in the source selection window using SoapySDR.
The sample processing rate seems to top out at 192ksps regardless of what sample rate is selected, causing the audio preview to cut in and out constantly. There is no CPU bottleneck as the CPU usage is under 10%.
I get this output on startup:
From extracting the AppImage, it seems like it is trying to read audio from /dev/snd/pcmC0D0c for some reason? If I use bwrap to disable it from accessing /dev/snd then it speeds up marginally, but only to about 384 ksps. I have no idea what it is doing, but it seems like it is blocking on something it shouldn't be when trying to process the input data?