bluez-alsa in ALSA-Distro

[lmaudio]

I have the question how to implement bluez-alsa on a Linux Mint 21.1 (Ubuntu 22.04) custom-distro that ships without Pulseaudio!?
How to make it work that bluez and bluez-alsa working by default in Audio-Player that just use the systemdefault alsa-device!
So that a user just has to pair and trust its bt-device and push play!?

In Linux Mint 21.1 (Mate) the bluez/pulseaudio-sound is really stable and working. But if i remove Pulseaudio it doesn't matter, what sounddriver i choose in Player - there is coming sound out of my laptop speaker, but not out of the paired bt-box!

I know the options and documentary of bluez-alsa are really much, i tried a lot from the wiki - but these are all steps for advanced users with different settings.

Short: i just want to prepare and rebuild a Linux system with a preconfigured bluez ALSA-based soundsetting and working bluetooth over the default ALSA soundcard in System WITHOUT Pulseaudio!

Could somebody help, giving me some tips!?!?

[arkq]

It all depends on the purpose of the distro you are trying to build. As for now, bluez-alsa repo provides a viable solution for integrating Bluetooth audio with ALSA ecosystem for small/dedicated end devices. The simplest example of that is a Bluetooth speaker based on e.g. Raspberry Pi. However, if one would like to create featured desktop-like OS, there are some issues/limitations. The culprit of all issues with "bluez-alsa for desktop" is the fact that bluez-alsa does not provide any sound server (audio routing and mixing). So, if it will be enough for you to create a static configuration, then probably you can achieve what you want by reading ALSA documentation for asoundrc configuration file https://www.alsa-project.org/wiki/Asoundrc and manual pages of bluealsa and all utilities distributed by this repository.

Anyway, if you want a dynamic configuration, then there are some options, but non of these are in this repo. The first thing that you probably want is audio mixing. You can get it from @borine's fork of bluez-alsa: https://github.com/borine/bluez-alsa Also, you can look at this: https://github.com/borine/bluealsa-autoconfig I've never been using bluealsa-autoconfig by myself, though. So, the best person to elaborate more on that topic is @borine :)

[graham8]

I'm going to do that annoying thing of responding with 'what's wrong with pulseaudio?' As @arkq says, you will lose it's audio routing capabilities. If you have a single application that might not be so bad. But ....

A difficulty I can see is that ALSA won't know your BT device exists until it's connected. Your application will need to keep polling dbus or wait for a dbus signal until the audio sink shows up. If you don't know what that means then I recommend you stick to pulseaudio unless you have a really strong reason to avoid it. You may find pipewire suits you as an alternative but I've never tried it.

[borine]

Linux Mint is a desktop OS, and has PulseAudio tightly integrated. This means that almost every GUI application is pre-configured to use PulseAudio, and for some applications it is even a compiled-in dependency. In general, this is a good thing. Desktops need features such as multiple applications playing sound at the same time, audio stream routing and re-routing, and a centralized control panel to manage it all. PulseAudio provides all these things, and removing PulseAudio removes all those features, leaving a desktop with somewhat broken audio. BlueALSA does not provide any of these audio management features, and is therefore not usually a good choice for Desktop systems. Why do you want to remove PulseAudio?

I don't know what application is used as audio player on Linux Mint. If it successfully sends audio to the sound card then at least it appears to work with ALSA. So most likely you need to work out how to tell it which PCM device to use; it almost certainly using the default PCM, and you need it to use the bluealsa PCM.

You could try redefining default with an entry in your ~/.asoundrc file:

pcm.!default bluealsa

Restart the audio player application so that it re-reads the ALSA config, and hopefully now you will have sound to bluetooth. Then to switch back to the sound card you would have to remove that entry from ~/.asoundrc and re-start the audio player.

There are some notes in the wiki on using BlueALSA as the default device, as you can see there it is not trivial. If you prefer you could try my ALSA autoconfiguration service from the link given by @arkq above, but whether that works for your specific application depends on how it uses the ALSA API.

If you want a "Just Works" solution for a Desktop system, then IMHO PulseAudio or Pipewire give a better experience.

BTW the bluealsa-autoconfig service only writes ALSA configuration entries, it has nothing to do with pairing.

[graham8]

BTW the bluealsa-autoconfig service only writes ALSA configuration entries, it has nothing to do with pairing.

I realised my mistake. If the OP is using a desktop there's a BT app in LM that does that which I doubt has any connections to pulseaudio.

[lmaudio]

bluez5

[lmaudio]

Thank you for answering.

The purpose of our little Distro-project is a stable DAW basing on Linux Mint.
For professional Audiosupport, less latency, comfortable usability and maximum stability we build our distro with Lowlatency Kernel, ALSA and the JACK Audioserver.
For Routing wie have patchbay-apps and the JACK Audioserver.

So it's more than just a standard desktop-system.

Pulseaudio is great and getting stable and better all the years, but for our special system wie prefer this configuration.
And hey, you can have a look @ https://qstudio64.tumblr.com : our Audiosystem is NOT broken. ;)

So ya, it's maybe simple, but we just need a static bluez-alsa and alsa configuration that just sends the sound to the default alsa soundcard after a user is pairing with bluez. Without breaking the whole soundsystem. Means: if i switch Bluetooth off, all players should use the default alsasoundcard again!
So a script to enable and disable the .asound.conf could be solution, but it's little confusing the not so advanced users.

I am just searching for the right .asound.conf settings to do this in system and remaster the system, so that is bluetooth working with Alsa for everyone.
As i read the description here, this should be the purpose of bluez-alsa.

So great, that bluez-alsa has so many options and is good documentated.

I will check your autoconfig tip, but would be happy, if somebody give me some more tips to realize this concrete static configuration

[borine]

realize this concrete static configuration

So there's the rub. In a static configuration, default refers to one PCM device, and always refers to that same PCM device. From your description, you need a "dynamic" configuration whereby default can vary its definition over time, and applications somehow magically know when its changed so that they should refresh their configuration caches. ALSA does not provide any such dynamic elements. Think of it this way: suppose default is something like plughw:0,0. Then you attach a USB sound card and expect applications to use that instead. How would you achieve that?

The kernel driver assigns card number 1 to the USB device, so in an alsa-lib configuration its PCM name would be plughw:1,0. If your application has a menu to choose the output device, then the new PCM may appear in the menu (depends on the application), or you can re-define default and re-start the application, or you can stop the application and start it with the new PCM as a command-line parameter or perhaps as an environment variable. So basically the same options are available when a BlueALSA device connects. Whatever solution you use for the USB case, it should be possible to do something similar with BlueALSA.

One gotcha is that some applications listen for udev events as the "magic" to tell them a sound card has appeared or disappeared. There is no such udev event for a BlueALSA device. That is one aspect that my bluealsa-autoconfig service is intended to address, it will generate a udev "change" event on card 0 whenever a BlueALSA device connects/disconnects. So it may be useful if your application(s) work that way.

[graham8]

Hmmm. You still haven't said exactly what you don't like about pulse. And if your goal is low latency I'm surprised bluetooth is in the mix at all!
@borine is correct, ALSA doesn't have the ability to switch sinks or at least it would be very difficult to implement - I've not come across any scripts that could give you an example to follow.

I did once set up a system where audio was routed to two sinks at once. That might work if you had a way of muting the internal audio of the device. You use the multi plugin and have to insert rate conversions if the two sinks don't support the same samplerates. The problem is, ALSA needs to be able to open both sinks so you can't just split the signal. I don't think ALSA falls back to default or sysdefault automatically - that has to be done by your application. The loopback device can help since ALSA can always open an input on a loopback even if the output (eg BT) isn't there.

All-in-all ALSA is a nightmare, which is why pulseaudio, jack, etc were invented.

[lmaudio]

@graham8 it's not, that i don't like Pulseaudio!
If you are on a standard Desktop-System like Debian, Ubuntu, Linux Mint..and like to hear audio, watch movies or surfing the internet, everything is really fine with this powerful pulse. Some years ago it was sometimes unstable or made some troubles in some systems or with some hardware- or you had to read a lot to configure it right to get audio working really stable.
But as i noticed the last years it's a stable and good standard in linuxworld now.

That apps like Firefox or Chromium makes pulse to a hard dependency (and not ALSA) was in my opinion a really bad and maybe unnecessary decision that breaks the sound in some browsers in some ALSA-based distros. And yes, there are many that prefer for multiple reasons ALSA (and JACK or Pipewire) instead of pulse. And a lot of Browsers like Brave, Opera (Chromium-based) and Palemoon,..showing that there is no really need for.

ALSA is the main soundarchitecture and sounddriver in Linux(kernel) - if you like it or not. Pulse, Jack, Pipewire,..just setting on ALSA.

In our little distro-project is the focus on stable and professional audio with a lot of audiointerfaces and (midi)-controllers.
Just since 10 years when we started we choosed ALSA and JACK as the default soundsystem in our distro - but everytime you can bring pulse back with just a three or four packets install and a reboot!
With KXStudio and its apps CADENCE, Catia, Claudia,..we found great tools to control and configure ALSA and JACK for pro-audio use.
Pulseaudio is resampling the signal and makes really highdefinition audio sounds like a mp3, IF you not take othe settings.
As a dj, home-producer and audiophile i don't want or need some crack-sounds in my audio, i don't want to hear a bad resampled audiofile and i don't want to fix pulse, IF its crashing or having no sound for unknown reasons!
Not on stage during a gig or in a recording session!
And this is exactly my bad experience in the past with pulse...but just some years ago.
ALSA and JACK working really fine and stable in our system and there are many different audiosettings-options and setups for individual needs, but 90% of them the user can do with gui and not in terminal or to configure some files.
Of course you can also do it in terminal also and Pipewire is "on board" too.

So hey, for this moment i give up with studying bluez-alsa for time reasons, i tried some hours to get it working - but i will come back in the future and still interested, because i think this is what i am looking for, to help people realize bluetooth getting working without pulse in our system.
At this time people that need bluetooth just have to reinstall pulseaudio and reboot and pairing with bluez. Easy.

But as i told you, our little distro is special for pro-audio and most of our users just working with high class audiointerfaces and good old cables.
Bluetooth produces a lot of latency and is a permanent security risk on every device! I use Bluetooth sometimes, yes.
But i don't like it really much.

So for this moment it's not the main focus to get bluetooth really working with ALSA. People are free to experiment with bluez-alsa and maybe it's more easy that i experienced to get bluetooth-alsa-audio working.

And all the people that really wants or need pulseaudio can install in some easy steps.

For us it's really important to give advanced users as novice users or people coming from windows/mac a great, easy and stable experience and many options with GNU/linux audio.

(Sorry for this long post, but hey, you asked me two times! ;-)

[borine]

So let's forget pulse, and concentrate on what is installed on this system. Now we know its JACK. So how do you plan to have JACK used with Bluetooth? I did some experiments a couple of years ago, and my conclusions are documented in the BlueALSA wiki here: https://github.com/arkq/bluez-alsa/wiki/Using-BlueALSA-with-the-JACK-Audio-Connection-Kit

If you intend that applications should access Bluetooth devices through the JACK API, then the biggest problem I can see is that I found no way for JACK to cope with removable devices. Whether BlueALSA or USB, when I disconnected then the JACK client fell over. So you need a solution for that. I've never used patchbay, so perhaps that can cope. If you can explain how your system deals with removable devices such as USB cards, then we may be able to find a Bluetooth solution modelled on that.

If you intend that applications should by-pass JACK and talk directly to the ALSA API for Bluetooth, then please explain how that is done. Again without more detail it is impossible for us to determine if BlueALSA is suitable.

[lmaudio]

Forget about JACK! (If its more complicated)

We just need to know how to integrate and configure bluez-alsa to get Bluetooth Wirkung without pulseaudio. Linux Mint is using systemd, so maybe this could help you!?

USB-Audio interfaces has to be supported from alsa-driver, upnp-ready or they don' t work.

If i put an usb-soundcard on, i have different options: i can choose the soundcard in apps and players and control with the alsa.conf the priority of what is the default sound card. Most apps and players are using the alsa default device.
Or i can start JACK and control the different ALSA soundcards with the kxstudio-app CADENCE!
Cadence is using an autogenerated .asoundrc file in home directory!
There is the Option to start an Alsa- Loop-Jack bridge (this brings e.g.sound from browsers if i wanna use Ardour, mixxx or other apps at the same time).
So hey yea, in our system is not the focus that everything is running without thinking and doing: the user has to know what to do: different situations- different Setups.
But like i wrote: 90% is to handle via GUI apps.

And this is what i want to serve:

A stable Desktop-DAW basing on Ubuntu/Linux Mint, where you can configure the sound fast and without terminal.

For me would be enough to know how to get Bluetooth with alsa and without pulseaudio over the onboardchip working with bluez-alsa.

And that i can integrate this in the next release.

I think if THIS is working, people could easy modify this for an usb-soundcard configured in Alsa too!?

And for the plug n play situation: its not aa bug or a oroblem (for me), if somebody puts the usb-interface off and breaking Sound.
If you do so, just configure your sound fast and easy again with cadence.
You can start and control JACK with cadence everytime you need more than just ALSA or you can make it as an autostart service.

if you use more than 1 soundcard, users have to think and configure for their needs.
I think using or switching to an usb-soundcard is not so frequently often, like with removable drives!? Just get your setup right and record, play music..

ALSA is the main sounddriver and systemdefault in our distro.

But you have many options.

Last: bluez is working in our Linux Mint based distro for pairing..but there is no sound out of bt-box without pulseaudio.

Anyway. I just think that it will be no big thing to get bluez-alsa working in our system...
I just have to und erstand and find the way to do so.

Talking just about to get ALSA/Bluetooth working with the default soundcard

[lmaudio]

How would you edit this .asoundrc file (for example) to get audio-output over bluetooth using bluez-alsa!!?:

# playback device
pcm.aloopPlayback {
  type dmix
  ipc_key 1
  ipc_key_add_uid true
  slave {
    pcm "hw:Loopback,0,0"
    format S32_LE
    rate {
      @func igetenv
      vars [ JACK_SAMPLE_RATE ]
      default 44100
    }
    period_size {
      @func igetenv
      vars [ JACK_PERIOD_SIZE ]
      default 1024
    }
    buffer_size 4096
  }
}

# capture device
pcm.aloopCapture {
  type dsnoop
  ipc_key 2
  ipc_key_add_uid true
  slave {
    pcm "hw:Loopback,0,1"
    format S32_LE
    rate {
      @func igetenv
      vars [ JACK_SAMPLE_RATE ]
      default 44100
    }
    period_size {
      @func igetenv
      vars [ JACK_PERIOD_SIZE ]
      default 1024
    }
    buffer_size 4096
  }
}

# duplex device
pcm.aloopDuplex {
  type asym
  playback.pcm "aloopPlayback"
  capture.pcm "aloopCapture"
}

# ------------------------------------------------------
# default device
pcm.!default {
  type plug
  slave.pcm "aloopDuplex"
}

# ------------------------------------------------------
# alsa_in -j alsa_in -dcloop -q 1
pcm.cloop {
  type dsnoop
  ipc_key 3
  ipc_key_add_uid true
  slave {
    pcm "hw:Loopback,1,0"
    channels 2
    format S32_LE
    rate {
      @func igetenv
      vars [ JACK_SAMPLE_RATE ]
      default 44100
    }
    period_size {
      @func igetenv
      vars [ JACK_PERIOD_SIZE ]
      default 1024
    }
    buffer_size 32768
  }
}

# ------------------------------------------------------
# alsa_out -j alsa_out -dploop -q 1
pcm.ploop {
  type plug
  slave.pcm "hw:Loopback,1,1"
}

[borine]

That .asoundrc file is for making ALSA application streams available as JACK ports in your patchbay. The discussion here is about making removable ALSA device streams available, either to JACK or not. The most important factor to consider is that they are removable devices; that is why I compared BlueALSA to USB. You said:

And for the plug n play situation: its not aa bug or a oroblem (for me), if somebody puts the usb-interface off and breaking Sound.
If you do so, just configure your sound fast and easy again with cadence.

So, if the Bluetooth device disconnects and breaks sound, are you happy that the user can fix it "fast and easy with cadence"? If so then use the same approach for BlueALSA as you do for USB - when a BT device connects, its the same as plugging in a USB dongle; when it disconnects its the same as unplugging the dongle. To make a BlueALSA device appear as a new entry in the ALSA configuration in the same way as a USB device appears when plugged in, you will need some service to edit the configuration. This is because ALSA has built-in support for soundcards so that the config API gets the list of cards from the kernel, but has no equivalent support for software devices. There is an example script to do this in the wiki here: https://github.com/arkq/bluez-alsa/wiki/Using-BlueALSA-as-default-ALSA-PCM, or my bluealsa-autoconfig service, linked above, can be used.

[lmaudio]

The point is that it everytime ends in the error-message: bt-connection file missing!

i was following the wiki for Ubuntu-based distros in your wiki here: https://github.com/arkq/bluez-alsa/wiki/Setting-up-a-USB-audio-device-as-a-Bluetooth-speaker-under-Ubuntu

But if i paired the bt-device it gets connected and than again not! with the error-message i wrote above.
IF i reinstall pulseaudio and its bluetooth module, i can connect and hear music over bt - but just without bluez-alsa and over pulse.

i think is maybe just a small thing, maybe just a line to edit - but i don't know where to find it.
bluez in Linux Mint 21.1/Ubuntu 22 depends and works with pulse. So how to configure it to work without pulse!?

so it seems in my case it's more a problem of understanding how to get bluez running correctly without pulse, than to configure bluez-alsa right!?

[borine]

error-message: bt-connection file missing

I've never seen that message. Is that the exact text that appears? If so its not from BlueALSA, and not from Bluez, I think.

i was following the wiki ...

That wiki page is for audio input, we need audio output. Also, IMHO, it has a number of inaccuracies, but others may disagree.

But if i paired the bt-device it gets connected and than again not!

That may be a bug in Bluez. The error message confuses me, but if we ignore that then you may be seeing the same issue described here: #554. Ubuntu 22.04 uses Bluez 5.64 which is known to have that bug. I describe a fix in the comments there. If that does not work for you then you may have to give up on using BlueALSA until your system can be upgraded to Bluez 5.65 or later.

[EDIT]
Another thought - if you wish to initiate the connection request from the remote speaker (eg many bluetooth speakers and headphones attempt to auto-connect when powered on), then Bluez needs to be told to "trust" the remote device, or else it will reject that connection request. Some BT management applets/applications automatically set a paired device as trusted, but bluetoothctl does not. After pairing it is necessary to do

trust xx:xx:xx:xx:xx:xx

in bluetoothctl to permit autoconnect by the remote device. So perhaps this is the issue for you, not the Bluez cache problem. Its not possible to tell without seeing the actual bluetoothctl session.