The times I have been successful at pairing bluez as a speaker I had pulseaudio (or pipewire with bluez) running and then paired the phone afterwards. However I haven't done this with pulseaudio in system mode. FYI if you enable system mode then pulseaudio uses the /etc/pulse/system.pa file to load, while the normal way to use pulseaudio is to have it autospawn for individual user sessions (it autospawns when you try to access pulse, e.g a pactl command, or just "pulseaudio"). The user session method uses the /etc/pulse/default.pa file to load. The user can also copy the user specific files to ~/.config/pulse and tweak them there for a user specific adjustment.

Also it will be worth noting that the bluetooth modules are automatically loaded in default.pa, while they are absent in system.pa. You could try copying those lines over to the system.pa module and experimenting that way. Another note, I'm not sure how the " --disallow-module-loading" bit will affect you trying to load bluetooth modules, but to me it looks like whatever is in system.pa gets loaded still. Try copying the bluetooth module lines from default.pa to system.pa if you're going that way (pasted below)
Then check with "pactl list modules short" after starting to see if they are loaded.

There is also the "module-suspend-on-idle" module loaded in both setups. That may automatically disconnect after an idle time so you could try experimenting with removing that to see if it helps.

The automatic reconnection is one I haven't figured out yet, although I've generally only used audio over bluetooth from the gui which can be reconnected easily enough, until you logout or reboot. bluetoothctl shows the phone is still paired and trusted after, but is not connected. E.g. in plasma my laptop sees the phone and says it can connect, but it fails anyway. Same with bluetoothctl. One thing that did make it work was running "hcitool cc <bluetooth address of phone>", which seems to connect it for a second, and then I can reconnect from the gui like normal after. If you figure that part out let me know!

Also one other thing: The audio streaming on bluetooth on my laptop is utter crap because I have some broadcom wifi/bluetooth all-in-one card (its been the only downside to this laptop). When the wifi is enabled, the sound stutters and cuts out constantly. If I disable the wifi then it works fine. Just something to watch out for if you have audio streaming problems afterward. I'm not sure how the bluetooth setup is on the pizero.

Don't get me wrong, the doctor did not prescribe me the use of pulseaudio ... and I'm perfectly ok to not use it for this BT speaker project ... in fact any way to get the digital audio, from BT, decoded and played back on analogue speakers, connected to the audio out, is fine for me ... as long as it's not a burden or overkill.

I had some time this evening to play around with the bluetooth speaker setup and I think I have a bit better of an idea of how it works now. Note that this is on slackware64-current, with the latest pulseaudio-14.2 (also works the same on pipewire with bluez enabled).

First on pulseaudio:

Just use it with the stock configs. If you want to run it on the command line you can use "pulseaudio -D" to start and daemonize it right away. E.g. I did that from my user account logged in on tty to start pulseaudio. This uses the pulseaudio's "default.pa" settings, which loads the bluetooth modules at startup (also works the same when running "pulseaudio -D" from root, although I'm not sure on the implications of that).

Second on bluetooth:

Without touching anything the way the agent is chosen seems to be dependent on what the session is doing. When logged into a graphical session it runs with the "DisplayOnly" agent, which does pin verification at both the phone and computer end. If you override that with "bluetoothctl --agent=NoInputNoOutput" then that only works as long as you have bluetoothctl open and running. Once you quit it defaults back to "DisplayOnly".

The upside is that if you are not running a graphical session and are just logged in from tty, it seems to use "NoInputNoOutput", which you can pair just by selecting it from the phone, no verification is used. However, that doesn't work out of the box with the bluetooth configs. I had to edit my /etc/bluetooth/main.conf file to get the cli pairing to work. I have the following lines uncommented:
With that I see <my machines name> from the bluetooth list on my phone, tapping it connects and I just have to accept the pairing on my phone. Then playing music on my phone to the bluetooth speaker works fine. Still might have to repair but it seems to survive reboots fine. Only downside is it would be nice to have a fixed pin or something, for security. Apparently theres a "simple-agent" example python script that the bluez devs made that does fixed pin. I havent tried it.

tldr: just start "pulseaudio -D", running on the cli with the /etc/bluetooth/main.conf set up as above will use the "NoInputNoOutput" agent, which is simple to connect to from the phone end. If you have a graphical session running then you will be stuck with "DisplayOnly", unless you override.

HTH

Use BlueZ + bluez-alsa

Run bluealsa-aplay, connect your BT audio source, and you are in the game.

However, not every BT USB dongle correctly deal with SCO streams. I do not recommend ISSC chips, they loose SCO packets. CSR based dongles works OK.

I will try that.
The plan is to use a RPI ZeroW (modified to add analog output) with the onboard wifi/bt

That's not amongst the Slackware packages ... but I found it in 3'rd party Slackonly x86_64 : bluez-alsa-1.3.1-x86_64-1_slonly.txz
No package for SlackwareARM though ... I will think it over again
There is a nickname that keeps on coming into my mind: pusaudio :-(

Just build it. You need only gcc+binutils+make, they should run on your RPi without problem.

It's not an official package, but is available on SBo.

Some backstory, if you're not aware. Prior to BlueZ 5.x, BlueZ was able to interact directly with alsa. However, with 5.x, they removed that ability, which forced Pat's hand to either break Bluetooth audio, keep BlueZ at an EOL/deprecated version, or add pulseaudio. He obviously chose the latter and 14.2 was the first stable release with pulseaudio. Fast forward a bit and some random developer(s) decided they wanted to keep using newer BlueZ without pulseaudio, so they implemented bluez-alsa, which allows Bluetooth audio without pulseaudio.

Since Slackware doesn't need BlueZ to have direct interaction with alsa (since pulseaudio is installed), you won't find an official bluez-alsa package in Slackware.

I wonder what made Pat change his mind in pam, which I see has made it's way into current's changelog.
Anyway after 5 years or so of 14.2 i have come to the conclusion that PulseuAudio stands for: Purulent Ulcer Linux Sound Eczema
There are far more bad things that came with PulseAudio than the actual good things especially if you like to work on the text console.

Anyway even alsamixer and aplay have dependencies on pulseaudio ... I think the Slackware BT speaker is impractical with Slackware

What is the problem that is stopping you from using slackware as a BT speaker?

Pulseaudio is already set up and works with bluez out of the box. The only thing you have to do is make sure pulse is started.

The other requirement is to set up your connection policy for bluetooth, which is done with the config for bluez, not with pulse. You would have to set that up regardless of what is handling your audio; pulse or bluez-alsa

I don't want to interact with X to have it working ... I actually don't want to even do anything else appart turn n the RPi that I will use for this job ... ideally the RPi will not even have X installed.
Don't gt me wrong : I've been a Slackware user for much longer then 14.2 it's just that pulseaudio came with 14.2.

However, it is worth the money and time spent on this particular project, specially when your requirements are pure-ALSA and no LinuxPAM, probably also... no elogind?

After all, looks like you can buy a fine Bluetooth audio receiver with 4,29 EUR...

https://www.ebay.it/itm/Receptor-Blu...o/401711953914

From what I know, in the European Union a pack of cigarettes costs more than 4 EUR and a coffee ordered on bar from a little town is at least 1 EUR.

I know (you can have a complete 5W BT speaker system for 10Eur) ... but I wanted the RPi to do some other stuff too (all with no user iteraction ... all driven from udev like I've already done on my home made AP)

Yes, BUT from what I know, Slackware (as many other distributions) probably is not designed to be a pure audio-server - and by this I understand being: an booting and launching some kind of audio server which interacts with Bluetooth, without any user login.

Then you talk about a system wide Bluetooth audio server launched by init.

You don't need X running to run pulseaudio or use it as a bluetooth speaker, you can run it from the command line as well. This can be achieved via the system mode (i.e. using /etc/rc.d/rc.pulseaudio), or from a user's login shell. I would highly recommend the user instance since system mode does not recommend loading modules, and you would have to make changes to the system.pa file to sort that out.

Now if you are trying to start pulseaudio as a user instance at boot with no interaction from a user then elogind is going to get in your way. Pulseaudio remains running until elogind notifies that the user session has ended. If elogind is not used then pulseaudio will auto exit after 20 seconds of idle time. Note I am assuming you are on current here. If you are on 14.2 then console kit does the same thing.

The reason I mention idle exit is because if you launch pulseaudio from a script without a full elogind session it will exit after 20 seconds. You can work around this by disabling the exit-idle-timer. Something like the following in /etc/rc.d/rc.local will provide a running user pulseaudio instance from boot:
What that does is launch pulseaudio as your user, which loads the bluetooth modules by default, and will not exit. You will still have to configure bluez in /etc/bluetooth/main.conf to allow pairing.

1 members found this post helpful.