BLUEALSA(8) | System Manager's Manual | BLUEALSA(8) |
bluealsa - Bluetooth Audio ALSA Backend
bluealsa -p PROFILE [OPTION]...
bluealsa is a Linux daemon to give applications access to Bluetooth audio streams using the Bluetooth A2DP, HFP and/or HSP profiles. It provides a D-Bus API to applications, and can be used by ALSA applications via libasound plugins (see bluealsa-plugins(7) for details).
Without this option, the default is to use all available HCI devices.
It is mandatory to enable at least one Bluetooth profile. For the list of supported profiles see Profiles in the NOTES section below.
In order to disable given audio codec (remove it from the list of audio codecs enabled by default), the NAME has to be prefixed with - (minus) character. It is not possible to disable SBC and CVSD codecs which are mandatory for A2DP and HFP/HSP respectively.
By default BlueALSA enables SBC, AAC (if AAC support is compiled-in), CVSD and mSBC (if mSBC support is compiled-in). For the list of supported audio codecs see the "Available BT audio codecs" section of the bluealsa command-line help message.
By default the volume of all PCMs of a device is set to 100% (full volume) when the device is first connected. For some devices, particularly headphones, this can lead to an unpleasant experience. This option allows the user to choose an alternative initial volume level. Only one value can be specified and each device on first connect will have the volume level of all its PCMs set to this value. However, a device with native volume control may then immediately override this level. On subsequent connects the volume will be set to the remembered value from the last disconnection. See Volume control in the NOTES section below for more information.
This option is required when using bluealsa with applications that close and then immediately re-open the same PCM as part of their initialization; for example applications built with the portaudio portability library and many other "portable" applications.
It can also be useful when playing short audio files in quick succession. It will reduce the gap between playbacks caused by Bluetooth audio transport acquisition.
The MODE can be one of:
The TYPE can be one of:
If CPU power consumption is not an issue, one might safely select best as the algorithm type. Also, please note that the true quality is determined by the selected bit rate or used VBR quality option (--mp3-vbr-quality).
The MODE can be one of:
The NUM can be one of:
A2DP AAC specification requires that for the constant bit rate (CBR) mode every RTP frame has the same bit rate and for the variable bit rate (VBR) mode the maximum peak bit rate limit is also per RTP frame. However, a single RTP frame does not contain a single full second of audio. This option enables true bit rate calculation (per second), which means that per RTP frame bit rate may vary even for CBR mode. This feature is not enabled by default, because it violates A2DP AAC specification. Enabling it should result in an enhanced audio quality, but will for sure produce fragmented RTP frames. If RTP fragmentation is not supported by used A2DP sink device (e.g., headphones) one might hear clearly audible clicks in the playback audio. In such case, please do not enable this option.
Please note, that this option does not necessarily mean that the variable bit rate (VBR) mode will be used. Used AAC configuration depends on a remote Bluetooth device capabilities.
The MODE can be one of:
bluealsa provides support for Bluetooth Advanced Audio Distribution Profile (A2DP), Hands-Free Profile (HFP) and Headset Profile (HSP). A2DP profile is dedicated for streaming music (i.e., stereo, 48 kHz or more sampling frequency), while HFP and HSP for two-way voice transmission (mono, 8 kHz or 16 kHz sampling frequency).
The Bluetooth audio profiles are not peer-to-peer; they each have a source or gateway role (a2dp-source, hfp-ag, or hsp-ag) and a sink or target role (a2dp-sink, hfp-hf, hsp-hs). The source/gateway role is the audio player (e.g., mobile phone), the sink/target role is the audio renderer (e.g., headphones or speaker). The bluealsa daemon can perform any combination of profiles and roles, although it is most common to use it either as a source/gateway:
bluealsa -p a2dp-source -p hfp-ag -p hsp-ag
or as a sink/target:
bluealsa -p a2dp-sink -p hfp-hf -p hsp-hs
or with oFono for HFP support,
source/gateway:
bluealsa -p a2dp-source -p hfp-ofono -p hsp-ag
sink/target:
bluealsa -p a2dp-sink -p hfp-ofono -p hsp-hs
With A2DP, bluealsa always includes the mandatory SBC codec and may also include various optional codecs like AAC, aptX, and other.
With HFP, bluealsa always includes the mandatory CVSD codec and may also include the optional mSBC codec.
The full list of available optional codecs, which depends on selected compilation options, will be shown with bluealsa command-line help message.
The list of profile NAME-s accepted by the --profile=NAME option:
The hfp-ofono is available only when bluealsa was compiled with oFono support. Enabling HFP over oFono will automatically disable hfp-hf and hfp-ag.
BlueZ permits only one service to register the HSP and HFP profiles, and that service is automatically registered with every HCI device.
For the A2DP profile, BlueZ allows each HCI device to be registered to a different service, so it is possible to have multiple instances of bluealsa offering A2DP support, each with a unique service name given with the --dbus= option, so long as they are registered to different HCI devices using the --device= option. See the EXAMPLES below.
A profile connection does not immediately initiate the audio stream(s); audio can only flow when the profile transport is "acquired". Acquisition can only be performed by the source/gateway role. When acting as source/gateway, bluealsa acquires the profile transport (i.e., initiates the audio connection) when a client opens a PCM. When bluealsa is acting as target, a client can open a PCM as soon as the profile is connected, but the audio stream(s) will not begin until the remote source/gateway has acquired the transport.
The Bluetooth specifications for HFP and HSP include optional support for volume control of the target by the gateway device. For A2DP, volume control is optionally provided by the AVRCP profile. bluealsa provides a single, consistent, abstracted interface for volume control of PCMs. This interface can use the native Bluetooth features or alternatively bluealsa also implements its own internal volume control, called "soft-volume". For A2DP the default is to use soft-volume, but this can be overridden to use the Bluetooth native support where available by using the --a2dp-volume command line option. For HFP/HSP the default is to use Bluetooth native volume control.
When using soft-volume, bluealsa scales PCM samples before encoding, and after decoding, and does not interact with the Bluetooth AVRCP volume property or HFP/HSP volume control. Volume can only be modified by local clients. (Note that Bluetooth headphones or speakers with their own volume controls will still be able to alter their own volume, but this change will not be notified to bluealsa local clients, they will only see the soft-volume setting).
When using native volume control, bluealsa links the PCM volume setting to the AVRCP volume property or HFP/HSP volume control. No scaling of PCM samples is applied. Volume can be modified by both local clients and the remote device. Local clients will be notified of volume changes made by controls on the remote device.
A2DP native volume control does not permit independent values for left and right channels, so when a client sets such values bluealsa will set the Bluetooth volume as the average of the two channels.
Volume level, mute status, and soft-volume selection can all be controlled for each PCM by using the D-Bus API (or by using ALSA plugins, see bluealsa-plugins(7) for more information). The current value of these settings for each PCM is stored in the filesystem so that the device can be disconnected and later re-connected without losing its volume settings.
When a device is connected, the volume level of its PCMs is set according to the following criteria (highest priority first):
its mute status according to:
and its soft-volume status according to:
When native volume control is enabled, then the remote device may also modify the volume level after this initial setting. Mute and soft-volume are implemented locally by the bluealsa daemon and cannot be modified by the remote device.
Note that bluealsa relies on support from BlueZ to implement native volume control for A2DP using AVRCP, and BlueZ has not always provided robust support here. It is recommended to use BlueZ release 5.65 or later to be certain that native A2DP volume control will always be available with those devices which provide it.
Emulate Bluetooth headset with A2DP and HSP support:
bluealsa -p a2dp-sink -p hsp-hs
On systems with more than one HCI device, it is possible to expose different profiles on different HCI devices. A system with three HCI devices might (for example) use hci0 for an A2DP sink service named "org.bluealsa.sink" and both hci1 and hci2 for an A2DP source service named "org.bluealsa.source". Such a setup might be created as follows:
bluealsa -B sink -i hci0 -p a2dp-sink & bluealsa -B source -i hci1 -i hci2 -p a2dp-source &
Setup like this will also require a change to the BlueALSA D-Bus configuration file in order to allow connection with BlueALSA services with suffixed names. Please add following lines to the BlueALSA D-Bus policy:
... <allow send_destination="org.bluealsa.sink" /> <allow send_destination="org.bluealsa.source" /> ...
Copyright (c) 2016-2023 Arkadiusz Bokowy.
The bluez-alsa project is licensed under the terms of the MIT license.
bluealsa-aplay(1), bluealsa-cli(1), bluealsa-rfcomm(1), bluetoothctl(1), bluealsa-plugins(7), bluetoothd(8)
January 2023 | BlueALSA v4.1.1 |