bluez-alsa | Bluetooth Audio ALSA Backend | Audio Utils library

by Arkq C Version: Current License: MIT

X-Ray Key Features Code Snippets Community Discussions(1)Vulnerabilities Install Support

kandi X-RAY | bluez-alsa Summary

bluez-alsa is a C library typically used in Audio, Audio Utils applications. bluez-alsa has no bugs, it has no vulnerabilities, it has a Permissive License and it has low support. You can download it from GitHub.

Bluetooth Audio ALSA Backend

Support

Quality

Security

License

Reuse

Support

bluez-alsa has a low active ecosystem.

It has 667 star(s) with 145 fork(s). There are 43 watchers for this library.

It had no major release in the last 6 months.

There are 11 open issues and 402 have been closed. On average issues are closed in 118 days. There are 6 open pull requests and 0 closed requests.

It has a neutral sentiment in the developer community.

The latest version of bluez-alsa is current.

Quality

bluez-alsa has 0 bugs and 0 code smells.

Security

bluez-alsa has no vulnerabilities reported, and its dependent libraries have no vulnerabilities reported.

bluez-alsa code analysis shows 0 unresolved vulnerabilities.

There are 0 security hotspots that need review.

License

bluez-alsa is licensed under the MIT License. This license is Permissive.

Permissive licenses have the least restrictions, and you can use them in most projects.

Reuse

bluez-alsa releases are not available. You will need to build from source code and install.

Installation instructions, examples and code snippets are available.

Top functions reviewed by kandi - BETA

kandi's functional review helps you automatically verify the functionalities of the libraries and avoid rework.
Currently covering the most popular Java, JavaScript and Python libraries. See a Sample of bluez-alsa

Get all kandi verified functions for this library.

bluez-alsa Key Features

No Key Features are available at this moment for bluez-alsa.

bluez-alsa Examples and Code Snippets

No Code Snippets are available at this moment for bluez-alsa.

Community Discussions

Trending Discussions on bluez-alsa

Yocto: question on adding bluez-alsa in Yocto build

QUESTION

Yocto: question on adding bluez-alsa in Yocto build

Asked 2019-Dec-16 at 08:40

I am new to Yocto, I built core-image-sato for default machine (x86-qemu). I have below questions with adding recipe:

I want to add bluez-alsa in the build. I checked http://layers.openembedded.org/layerindex/branch/master/recipes/ and got the bb file (bluez-alsa_git.bb). For adding it, i created a directory (bluez-alsa) and created a bluez-alsa_git.bb file in it. Is this right method to add a new package?
Now after adding the bluez-alsa (as specified in step-1 above), I am building core-image-sato which is failing, because of dependency in systemd module (I see from bb file dependency in systemd module). Below is the error:

ERROR: Nothing PROVIDES 'systemd' (but /home/srawat/tree/yocto/yocto_x86/poky/meta/recipes-connectivity/bluez-alsa/bluez-alsa.bb DEPENDS on or otherwise requires it)

systemd was skipped: missing required distro feature 'systemd' (not in DISTRO_FEATURES)

ERROR: Required build target 'bluez-alsa' has no buildable providers. Missing or unbuildable dependency chain was: ['bluez-alsa', 'systemd']
#

What is the method to include "systemd" module now? Or

IOW in general, how to include dependent packages (talking about existing packages of layers.openembedded.org, no new packages) in image?

Further i have more existing packages to add, will use the suggested method to add them.

advance thanks

...

ANSWER

Answered 2019-Dec-16 at 06:04

Its best to include the layer which provides the recipe, this might help in bringing in needed direct and indirect dependencies as well as you also saw the missing dependency problem, however there is another side of the story, where the source layer might have further dependencies on other layers which might be too much of an ask for what one needs for adding a single recipe.

so in your case cherry-picking recipe seems to be a better approach since the source layer has quite a few deps plus this given recipe only has dependencies on core layer.

however the problem you have is that your distro policies do not use systemd but this recipe assumes systemd is enabled. so you have two ways

Enable systemd distro-wide by adding something like below to local.conf

DISTRO_FEATURES_append = " systemd" VIRTUAL-RUNTIME_init_manager = "systemd" DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit" VIRTUAL-RUNTIME_initscripts = ""
Remove need for systemd from the recipe

change

Source https://stackoverflow.com/questions/59350555

Community Discussions, Code Snippets contain sources that include Stack Exchange Network

Vulnerabilities

No vulnerabilities reported

Install bluez-alsa

or if you intend to stream audio from a Linux distribution using PulseAudio < 13.0 (see this issue).
alsa-lib
bluez >= 5.0
glib with GIO support
sbc
docutils (when man pages build is enabled with --enable-manpages)
fdk-aac (when AAC support is enabled with --enable-aac)
lc3plus (when LC3plus support is enabled with --enable-lc3plus)
libldac (when LDAC support is enabled with --enable-ldac)
libopenaptx (when apt-X support is enabled and --with-libopenaptx is used)
mp3lame (when MP3 support is enabled with --enable-mp3lame)
mpg123 (when MPEG decoding support is enabled with --enable-mpg123)
openaptx (when apt-X support is enabled with --enable-aptx and/or --enable-aptx-hd)
spandsp (when mSBC support is enabled with --enable-msbc)
libdbus
readline
libbsd
ncurses

Support

Using BlueALSA alongside with PulseAudio. Due to BlueZ limitations, it seems, that it is not possible to use BlueALSA and PulseAudio to handle Bluetooth audio together. BlueZ can not handle more than one application which registers audio profile in the Bluetooth stack. However, it is possible to run BlueALSA and PulseAudio alongside, but Bluetooth support has to be disabled in the PulseAudio. Any Bluetooth related module has to be unloaded - e.g. bluetooth-discover, bluez5-discover. ALSA thread-safe API (alsa-lib >= 1.1.2, <= 1.1.3). Starting from ALSA library 1.1.2, it is possible to enable thread-safe API functions. It is a noble change, but the implementation leaves a lot to be desired. This "minor" change does not affect hardware audio devices (because for hardware devices, this change is disabled), but it affects A LOT all software plug-ins. Random deadlocks are inevitable. My personal advice is to disable it during alsa-lib configuration step (./configure --disable-thread-safety), or if it is not possible (installation from a package repository), disable it via an environmental variable, as follows: export LIBASOUND_THREAD_SAFE=0. Couldn't acquire D-Bus name: org.bluealsa. It is not possible to run more than one instance of the BlueALSA server per D-Bus interface. If one tries to run second instance, it will fail with the "Couldn't acquire D-Bus name: org.bluealsa" error message. This message might also appear when D-Bus policy does not allow acquiring "org.bluealsa" name for a particular user - by default only root is allowed to start BlueALSA server. Couldn't get BlueALSA PCM: PCM not found. In contrast to standard ALSA sound cards, BlueALSA does not expose all PCMs right away. In the first place it is required to connect remote Bluetooth device with desired Bluetooth profile - run bluealsa --help for the list of available profiles. For querying currently connected audio profiles (and connected devices), run bluealsa-aplay --list-devices. The common misconception is an attempt to use A2DP playback device as a capture one in case where A2DP is not listed in the "List of CAPTURE Bluetooth Devices" section. Additionally, the cause of the "PCM not found" error might be an incorrect ALSA PCM name. Run bluealsa-aplay --list-pcms for the list of currently available ALSA PCM names - it might give you a hint what is wrong with your .asoundrc entry. Also, take a look at the "Using the bluealsa ALSA pcm plugin" bluez-alsa wiki page.

Find more information at: