SigDigger icon indicating copy to clipboard operation
SigDigger copied to clipboard

SigDigger: No audio in real-time mode with BladeRF (ALSA + PulseAudio / PipeWire)

Open Koksssssss opened this issue 8 months ago • 8 comments

SigDigger: No audio in real-time mode with BladeRF (ALSA + PulseAudio / PipeWire)

Description:

Hi everyone,

I’ve successfully compiled and installed SigDigger on Linux (Ubuntu 24.04) with the default audio stack: PipeWire + PulseAudio compatibility layer + ALSA. The application works perfectly in IQ file playback mode — recorded IQ files play audio without any issues.

However, when switching to real-time reception using a BladeRF via SoapySDR, the following error appears:

Failed to activate stream: RtAudio init error 'RtApiPulse::probeDeviceOpen: error connecting input to PulseAudio server.' Failed to start capture

Observations

  • Audio settings: Tried both PulseAudio and ALSA in the Audio Output settings.
  • File playback mode: Works well — demodulated audio plays normally.
  • Real-time mode: Always fails with the above PulseAudio error.
  • Sample rate: Lowering from 5 MSPS to 2 MSPS made no difference.
  • System sound: Works fine (e.g. YouTube in browser) when SigDigger is not running or in playback mode.
  • Temporary fix: Disabling pipewire, pipewire-pulse, and wireplumber, then launching SigDigger with:

SDL_AUDIODRIVER=alsa ./SigDigger

— allows real-time reception to work with audio.

However, system-wide sound (e.g. YouTube, apps) becomes unavailable due to ALSA being taken exclusively.

Hypothesis

SigDigger (or more precisely, RtAudio) may be falling back to PulseAudio even when ALSA is selected. On systems where PulseAudio is actually provided by pipewire-pulse, this can cause connection issues or misbehavior, especially when RtAudio doesn’t properly detect the active backend.

Question

  • Could SigDigger better detect PipeWire environments and avoid PulseAudio fallback if ALSA is selected?
  • Is there a way to force ALSA usage without RtAudio attempting Pulse?
  • Would it be possible to support PipeWire explicitly or provide a clean runtime config to avoid audio init errors?

Thanks in advance for your time and for this excellent tool!

I'm happy to test patches, share logs, or run diagnostics if needed.

Koksssssss avatar Mar 28 '25 11:03 Koksssssss

Quick update to clarify:

When launching SigDigger with pipewire, pipewire-pulse, and wireplumber fully stopped — and using: — the application does start without any errors, and the signal spectrum is visible. However, no audio is played at all:

  • No demodulated sound from SigDigger
  • No system-wide audio (e.g. browser, YouTube)
  • Changing frequency has no audible effect
  • The spectrum display is also noticeably laggy

So even though the application starts, there is no working audio, and the system loses all sound capabilities when PipeWire is disabled.

Just wanted to clarify this part, since the original post may have suggested that audio worked after stopping PipeWire — in reality, it only prevented the init error, but did not restore sound.

Thanks again!

Koksssssss avatar Mar 28 '25 12:03 Koksssssss

Update: Additional testing with SIGDIGGER_AUDIO_BACKEND and SDL_AUDIODRIVER

We attempted to explicitly force SigDigger to use ALSA by launching it with:

SDL_AUDIODRIVER=alsa SIGDIGGER_AUDIO_BACKEND=alsa SigDigger
However, the same error persists:

RtApiPulse::probeDeviceOpen: error connecting input to PulseAudio server
This suggests that either:

    RtAudio internally defaults to PulseAudio even when ALSA is requested;

    or the ALSA backend is not being recognized correctly by RtAudio at runtime;

    or the ALSA backend is unavailable/misconfigured on the system.

📋 System context:

    Ubuntu 24.04

    PipeWire removed, PulseAudio now active

    Devices visible via arecord -L and pactl list sinks

    System-wide sound (e.g. YouTube) works perfectly

    RtAudio still cannot initialize stream in real-time capture mode

Let us know if there's a way to explicitly disable PulseAudio fallback in SigDigger or RtAudio, or if you'd like us to test with a specific build flag or patch.

Koksssssss avatar Apr 01 '25 08:04 Koksssssss

Hi,

I will try to find some time these days to look into this. In the meantime, could it be that you have the Audio SoapySDR module installed in your system? That module is known to cause issues with the audio output, could you move it somewhere else and restart SigDigger? The module file is libaudioSupport.so in my system.

Thanks

BatchDrake avatar Apr 01 '25 09:04 BatchDrake

Thank you for your response! Your suggestion to move the libaudioSupport.so module out of the SoapySDR directory really helped — SigDigger now launches successfully.

However, audio playback in real time still doesn’t work: the system audio works fine, but SigDigger produces no sound. At the same time, recording audio to a file works properly — the saved file contains sound and plays back correctly in other applications.

Thanks again for your time and support!

Koksssssss avatar Apr 01 '25 12:04 Koksssssss

I can confirm same behaviour on Debian 12, without pipewire. Same errore in Alsa mode. No real time run.

Iu2ipb Ugo

UgoPoddine avatar Jul 18 '25 18:07 UgoPoddine

Hi,

Please try moving libaudioSupport.so somewhere else.

Cheers,

BatchDrake avatar Jul 18 '25 18:07 BatchDrake

Thank-you Gonzalo.

Issue solved Aldo for RealTime capture.

73, Ugo

BatchDrake left a comment (BatchDrake/SigDigger#276)

Hi, Please try moving libaudioSupport.so somewhere else. Cheers,

— Reply to this email directly, view it on GitHub , or unsubscribe . You are receiving this because you commented. Message ID: <BatchDrake/SigDigger/issues/276/3090406916 @ github . com>

UgoPoddine avatar Jul 18 '25 19:07 UgoPoddine

Can confirm the same issue on KDE Neon (Ubuntu 24.04). I'm using USRP B210.

Please try moving libaudioSupport.so somewhere else.

Removing soapysdr0.8-module-audio:amd64 helps with starting up the app but doesn't help when it comes to real-time audio.

Caraffa-git avatar Nov 15 '25 21:11 Caraffa-git