Closed Vinchethescript closed 3 months ago
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.
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.
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.
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.
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:
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.
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.
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.
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).
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.
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).
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
andmodule-alsa-sink
). Then, I configured PipeWire as of the PulseAudio integration wiki page, changingpulseaudio
topipewire-pulse
in thebluepulse
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 ofpavucontrol
, 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
f7e6ee5 (HEAD, tag: v4.1.1) Bug fix version bump (release 4.1.1)
--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