No sound on speakers with PipeWire.

[Vinchethescript]

Problem

I compiled and installed PipeWire on my Raspberry Pi 4 (running Raspberry Pi OS Bookworm) so that I could completely disable bluetooth from it (and have a more recent version that supported module-alsa-source and module-alsa-sink). Then, I configured PipeWire as of the PulseAudio integration wiki page, changing pulseaudio to pipewire-pulse in the bluepulse systemd service. I'm trying to use BlueALSA as sink, and I'm testing it with my phone (Galaxy S21 5G)

The problem is that BlueALSA receives the audio, but doesn't play it on the speakers. The bluepulse script creates the source for my phone when audio starts playing and, as of pavucontrol, PipeWire does receive audio data, but this audio is not played into the speakers.

I think that this is more of a PipeWire bug than a BlueALSA bug, but I'm adding this here so that a possible solution could be documented in the wiki.

You can only hear the phone's audio when you run bluealsa-aplay XX:XX:XX:XX:XX:XX, otherwise it is sent to the ALSA source and it's not played onto the speakers.

Reproduction steps

All I did is enable all the PipeWire services and BlueALSA (bluealsa -S -p a2dp-sink -c sbc -c mp3 -c aac -c aptx -c aptx-hd -c ldac --ldac-quality=high --ldac-abr) using systemd.

Then, I rebooted and triple-checked that everything was running and, even though everything was working, BlueALSA gave this problem. I also tried to restart all the services, but nothing changed.

Setup

• Raspberry Pi OS Bookworm
• BlueALSA v4.1.1
• BlueZ v5.66
• ALSA v1.2.8
• PipeWire v0.3.85
• Branch and commit: f7e6ee5 (HEAD, tag: v4.1.1) Bug fix version bump (release 4.1.1)
• Configure options:
• • --enable-manpages
• • --enable-aac
• • --enable-ldac
• • --with-libopenaptx
• • --enable-mp3lame
• • --enable-mpg123
• • --enable-aptx --enable-aptx-hd
• • --enable-msbc
• • --enable-rfcomm
• • --enable-hcitop
• • --enable-systemd
• • --enable-cli
• • --enable-debug

[borine]

I am intrigued by this. I've always found Pipewire Bluetooth support to be very good, and never imagined anyone would want to use BlueALSA on the same system. Anyway, your main problem here (there may be others, as this setup has never been tried before AFAIK) is with Wireplumber.

of pavucontrol, PipeWire does receive audio data

So you have not told Pipewire what to do with that audio stream. In a default install with Pipewire's internal bluetooth, then the default Wireplumber config sets up a loop from bluetooth source to default (speaker) sink. I think you will have to find a way to configure Wireplumber so that it does something similar when a new ALSA module source appears.

[Vinchethescript]

I've always found Pipewire Bluetooth support to be very good, and never imagined anyone would want to use BlueALSA on the same system.

I am trying to use BlueALSA on PipeWire because, AFAIK, it does not support decoding LDAC, and because I am more familiar with BlueALSA anyway.

So you have not told Pipewire what to do with that audio stream. In a default install with Pipewire's internal bluetooth, then the default Wireplumber config sets up a loop from bluetooth source to default (speaker) sink. I think you will have to find a way to configure Wireplumber so that it does something similar when a new ALSA module source appears.

I see. I'm trying to configure WirePlumber for that right now, but I can't seem to get it working at the moment.

[borine]

but I can't seem to get it working at the moment.

As noted in the wiki, the Pulseaudio module-loopback does not work with the bluealsa plugin as a module-alsa-source. Perhaps the Pipewire equivalent (whatever that is, I'm not a Pipewire expert) has similar difficulties. I happen to be looking into ways that the bluealsa plugin can be made to behave more like a hw ALSA device, especially for ALSA capture, but that work is likely to take several more months before it comes to anything useable,

In the meantime, if the Pipewire loopback cannot be made to work, then you will have to consider some other way of transferring the incoming stream to an output device. bluealsa-aplay may well be the best option for that.

[Vinchethescript]

but I can't seem to get it working at the moment.

As noted in the wiki, the Pulseaudio module-loopback does not work with the bluealsa plugin as a module-alsa-source. Perhaps the Pipewire equivalent (whatever that is, I'm not a Pipewire expert) has similar difficulties. I happen to be looking into ways that the bluealsa plugin can be made to behave more like a hw ALSA device, especially for ALSA capture, but that work is likely to take several more months before it comes to anything useable,

Yes, PipeWire presents the same issues as PulseAudio. I tried using both module-loopback from pactl and pw-loopback, and both returned the same result.

In the meantime, if the Pipewire loopback cannot be made to work, then you will have to consider some other way of transferring the incoming stream to an output device. bluealsa-aplay may well be the best option for that.

I see. For now I am going to disable PipeWire and enable bluealsa-aplay, until this is resolved.

[borine]

I've updated the wiki page with some notes on using pulse's module-loopback with BlueALSA sources, and also mentioned using bluealsa-aplay as an alternative. The bash script has been updated to include an option to automatically load module-loopback.

@Vinchethescript Does that description match what you did with load-module module-loopback?
What result did you get when using that module with Pipewire?

Now that you have demonstrated that the pulse load-module module-alsa-source command works with Pipewire, I would like to extend the wiki article to include what you have learned. Please could you tell:

• how did you disable Pipewire's internal Bluetooth support?
• did you need to modify the bash script in any way, or perform any additional manual configuration?
• did you try using bluealsa-aplay --pcm=pipewire instead of loading the alsa-module-source module?

Any other useful information that you can provide, including links to references to may have used, would be helpful.

I plan to upgrade my laptop to Ubuntu 24.04 later this year, so will lose my last pulseaudio installation, and will then investigate more the co-existence of BlueALSA and Pipewire.

[Vinchethescript]

I've updated the wiki page with some notes on using pulse's module-loopback with BlueALSA sources, and also mentioned using bluealsa-aplay as an alternative. The bash script has been updated to include an option to automatically load module-loopback.

I tried to use that script even with the loopback, but it just exits with a syntax error because s32le  is not present into sample_size.

@Vinchethescript Does that description match what you did with load-module module-loopback? What result did you get when using that module with Pipewire?

I got the same results as running it into PulseAudio.

how did you disable Pipewire's internal Bluetooth support?

I had to recompile PipeWire from scratch using the guide available on their repository. Before effectively building it, though, you have to run this command to disable all the Bluetooth functionalities:

meson configure builddir \
    -Dprefix=/usr \
    -Dbluez5=disabled \
    -Dbluez5-backend-hfp-native=disabled \
    -Dbluez5-backend-hsp-native=disabled \
    -Dbluez5-backend-hsphfpd=disabled \
    -Dbluez5-backend-native-mm=disabled \
    -Dbluez5-backend-ofono=disabled \
    -Dbluez5-codec-aac=disabled \
    -Dbluez5-codec-aptx=disabled \
    -Dbluez5-codec-lc3=disabled \
    -Dbluez5-codec-lc3plus=disabled \
    -Dbluez5-codec-ldac=disabled \
    -Dbluez5-codec-opus=disabled

Also, note that I built PipeWire version 0.3.85, as 0.3.65 (which is the available version on APT on Raspberry Pi OS Bookworm) does not support module-alsa-source and module-alsa-sink.

• did you need to modify the bash script in any way, or perform any additional manual configuration?

No, I did not do any manual configuration and I did not edit the bluepulse bash script.

• did you try using bluealsa-aplay --pcm=pipewire instead of loading the alsa-module-source module?

I just tried it, and it does show up on pavucontrol this time, meaning the audio passes through PipeWire, and there is sound on the speakers! I noticed, though, that there's more latency when audio is playing through PipeWire, while there's less latency when using ALSA directly, which I think is sort of normal.

Also, that command does not work as root (tested through the bluealsa-aplay service), which I think is normal because PipeWire is running as user and not as root.

[borine]

Thanks, that is all very helpful. Given that recompilation of pipewire is required, I think that this all too much to be added on to the existing pulseaudio wiki page. Would you agree that co-existence of Pipewire and BlueALSA is just not worth the effort?

s32le is not present into sample_size

oops! I'll upload a new version with that corrected ASAP.

[Vinchethescript]

Would you agree that co-existence of Pipewire and BlueALSA is just not worth the effort?

I think it depends on which codec someone needs, unless PipeWire supports decoding and playing high quality codecs such as LDAC. AFAIK, PipeWire doesn't support it, which is why I've been trying to use BlueALSA on PipeWire (I used a different library to compile BlueALSA with LDAC support, which includes decoding).

[borine]

I've just updated the wiki page https://github.com/arkq/bluez-alsa/wiki/PulseAudio-integration with information on how to disable pipewire bluetooth support. I still have not found any way to get the pipewire loopback module to work with bluealsa, but for me using bluealsa-aplay with pipewire gives good results.

[borine]

The wiki page Pipewire or PulseAudio Integration is now complete, documenting the working setup that I now have with Ubuntu 24.04LTS (pipewire 1.0.5, wireplumber 0.14.17, bluealsa 4.2.0). I think there is no way to get loopback working from a BlueALSA source because the BlueALSA PCM simply cannot deliver samples at a steady enough rate, but bluealsa-aplay is doing a good job for me in its place. Sure the latency is high, but as Bluez is unable to report stream delay to the remote source using AVDTP it has never been possible to synchronize with video on the phone anyway.

I'm closing this issue, but if anyone finds issues with the new wiki text please do open a new issue so that we can try to resolve them. (but please report issues specifically related to the bluealsa-agent program to the bluealsa-autoconfig issues list).