Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Raspberry Pi #21

Closed
ageorgios opened this issue Dec 26, 2016 · 14 comments
Closed

Raspberry Pi #21

ageorgios opened this issue Dec 26, 2016 · 14 comments

Comments

@ageorgios
Copy link

Any installation tutorial for compiling on raspberry pi for dependencies?

@Captain-Coder
Copy link

Captain-Coder commented Jan 12, 2017

I've got this working on my RPi 2 B with a cheap BT4.0 dongle. I use Arch, and blue-alsa is in AUR. All the dependencies (including make dependencies) are available from the pacman package manager. In case you are not using arch search around and you should easly find those for your linux flavor.

The AUR PKGBUILD does not specify armv7h architecture, so makepkg will not build it out-of-the-box but adding 'armv7h' to the architectures seems to be enough to make it work. Just makepkg it, or when not using Arch adapt the steps outlined in the linked pkgbuild to your system. After installation start bluealsa with systemctl start bluealsa.

That was the easy part :) If you test it with aplay at this point you can verify that all the connection/disconnection and stream setup works. But for me it was very glitchy and I could hardly make out any of the music I was playing. (Also be sure to use a 44.1kHz s16_le wav for testing, took me a while to figure this out!) Looking at the journal journalctl -u bluealsa.service -f, I saw many "resource busy" debug log lines that correspond to times of glitches. This happens when bluealsa writes via the pipe to bluez, which in turn should send this data using BT radio. The pipe has a limited buffer, and when full it notifies bluealsa of this, which then writes said debug statement.

So the real trick in getting this to work is to make sure the pipe gets cleared as fast as possible. For this we need to prioritize bluetoothd. I tried nice-ing it, and that helped a lot but I still had glitches, and that was on a fully idle system. So I ended up setting bluetoothd to rr-scheduling to force it to pre-empt any process and clear the pipe as fast as possible. This works a charm, no more glitches, but setting it up requires jumping through some hoops.

I created a drop-in configuration for the bluetooth.service which sets the CPUSchedulingPolicy to rr. But unfortunately that is not enough, since (currently) systemd is not able to set the cpu.rt_runtime_us property of the system.slice cgroup through configuration files. When this property is 0 (as is the default of the system.slice where bluetooth.service executes), any service setting any of the rt schedulings will get a permission denied. The workaround I used was to use the drop-in config to place the bluetooth service in the root slice. Another option would be to have a one-shot service that sets the cpu.rt_runtime_us value, and have bluetooth.service Require= this service (and go After= it). Or as the systemd developers suggest, recompile your kernel with CONFIG_RT_GROUP_SCHED=n. I chose the easy but nuclear option of placing it in the root slice (this can easly make a system unresponsive if bluetoothd ever misbehaves). The completed drop-in file then reads:

/etc/systemd/system/bluetooth.service.d/10-bluealsa.conf:

[Service]
CPUSchedulingPolicy=rr
CPUSchedulingPriority=50
Slice=-.slice

Restart the bluetooth and bluealsa services and you should be enjoying glitch free sound streaming from your RPi to your bluetooth device.

@humarf
Copy link

humarf commented Feb 14, 2017

I can confirm this is working even on a first generation raspberry pi. It creates a load of about 0.5.

@cjsthompson
Copy link

cjsthompson commented May 4, 2017

Hi!

I'm also looking forward to using bluez-alsa on a Raspberry Pi Model B+ because the analog input on it hisses a lot and I unfortunately don't have a monitor with HDMI/integrated speakers. I use this Raspberry Pi to watch movies with Kodi. It is running Arch Linux ARM. I thought a bluetooth speaker would fix my hissing problem, so I got myself a Voombox Travel. I got as far (with bluez-alsa) as being able to play the .wav files in /usr/share/sounds with aplay. But cmus freezes when I start it. I can't play any mp3s with sox's 'play'. And no sound in Kodi either yet. I guess I could install PulseAudio, but given the relatively limited hardware of the Model B+, I think bluez-alsa could be the better choice once I get it fully working.

@Captain-Coder
Copy link

@cjsthompson You might have to create a custom alsa config to direct audio (by default) to blue-alsa, but I thought it a bit out of scope to explain all that here too. There are other (blue-)alsa issue/support pages that deal extensively with that. I also have the arch/kodi combo on my system and it works with some caveats. The Kodi support pages/forum have some nuggets about how to direct kodi to use a custom audio device (http://forum.kodi.tv/showthread.php?tid=167008, this works for me) but I don't use the BT audio by default.

And that is the major caveat, if my BT headset is powered off (default) during system/kodi boot, it will not show up if you power it up later on. You have to restart kodi to get it to rescan the alsa devices and then detect the BT audio. You might be able to solve this with a systemctl drop-in to depend on specific BT devices being online?

As for freezing applications; I have not experienced this issue but I went straight for Kodi once the aplay worked. I've only ever had the kodi audio fail on me once when I accicentally turned my BT headset off when it was still playing. Kodi (or blue-alsa or alsa) proceeded to dump very loud noise to my hdmi output. So lets call that operator error. All I can think of is to check if the playing application actually uses the blue-alsa output. (If you have nothing hooked up to the hdmi/analog, playback on that might feel like a halted application also) And also check if the application uses the correct output format (sample size, rate, mono/stereo), if not then make it use an alsa plug or hwplug.

@jimjam-slam
Copy link

jimjam-slam commented Aug 19, 2017

I would also appreciate more detailed installation instructions, especially as this is being pushed by The Raspberry Pi Foundation as the preferred Bluetooth audio solution on Raspbian Stretch. I can only get as far as:

$ git clone https://github.com/Arkq/bluez-alsa.git
$ cd bluez-alsa
$ autoreconf --install
-bash: autoreconf: command not found
$ sudo apt-get install bluez-alsa
Package bluez-alsa is not available, but is referred to by another package.
This may mean the the package is missing, has been obsoleted, or
is only available from another source

E: Package 'bluez-alsa' has no installation candidate

I'm running Stretch on a Pi Zero W.

@infirit
Copy link

infirit commented Aug 19, 2017

I am not a debian user but....

First thing you want to do on debian is apt-get install build-essentials. With this a compiler, autotools and other build tools will be installed.

Then follow the dependencies as listed here :https://github.com/Arkq/bluez-alsa#installation. Most of the time you will want install the DEP-dev package for the ones listed. But his rule does not always work on debian so you will need to search and experiment.

The ./configure line will tell you what you are still missing.

@jimjam-slam
Copy link

Thanks a lot, @infirit. For other Pi users who're still figuring it out (like me), I've been able to install most of the dependencies by uncommenting deb-src http://archive.raspbian.org/raspbian/ stretch main contrib non-free rpi from /etc/apt/sources.list, then sudo apt-get update and sudo apt install using the package names listed in the .travis.yml file in this repo.

However, I couldn't find libfdk-aac-dev. It appears to be on the Debian repo, but I read that mixing Debian and Raspbian packages is a bad idea. So I'll try installing this without AAC support.

@jimjam-slam
Copy link

Installing build-essentials didn't appear to help with autoreconf :/

@jimjam-slam
Copy link

Welp, I feel silly—I was using Stretch Lite, and this is already installed in the full-fat version. Thanks for your help regardless!

@gkiranps
Copy link

For aac support I used,
https://github.com/mstorsjo/fdk-aac

clone repo,
$ libtoolize
$ autoreconf --install
$ mkdir build && cd build
$ ../configure
$ make
$ make install

Now you can build bluez-alsa with
../configure --enable-aac --enable-debug

make
make install

@arkq arkq mentioned this issue Sep 4, 2017
@ghost
Copy link

ghost commented Sep 4, 2017

@Captain-Coder Have you tried your fix on Raspbian Stretch? The file /etc/systemd/system/bluetooth.service.d/10-bluealsa.conf doesn't exist in the default installation, and adding those lines to /etc/systemd/system/bluetooth.target.wants/bluetooth.service (which seemed like the closest fit) did not help.

@gkiranps
Copy link

gkiranps commented Sep 5, 2017

I started bluealsa in rc.local.

I added
bluealsa &
To the end of /etc/rc.local.

@Captain-Coder
Copy link

Captain-Coder commented Sep 6, 2017

@leandrotlz, I have not tested on Raspbian Strech, just Arch.

When editing systemd services, you have to make the drop-in (*.service.d) directory yourself, aswell as the actual drop-in file. You can also use 'systemctl edit bluetooth' which will create the correct drop-in file to ammend the bluetooth.service. For further details please read 'man systemd' (Also assuming that Strech hasn't named it bluez.service or something else)

Please note that the files in /etc/systemd/system/...wants/* are symlinks to the actual service definitions (usually in /usr/lib/systemd/system/...) So the edits you made might not survive the next 'apt-get upgrade' if the bluez package gets updated. Allthough functionally they should work if you rebooted or, systemctl daemon-reloaded and restarted the bluetooth service and bluez-alsa service (in that order).

I read the "Jittery Audio" thread you came from, and be aware that when using bluez-alsa as sink, the roles relative to the pipe are reversed. ie: bluetoothd is writing to bluez-alsa but bluez-alsa does not have real time scheduling and thus does not preempt bluetoothd. This would look like missing packages from bluez-alsa's point of view. So try applying my fix to bluez-alsa instead of bluetooth (or perhaps to both). Also for further debugging, you could start by verifying (using top or ps) that the configuration was applied and bluetoothd (or the bluealsa) process actually got a high priority.

I am using this for a headset when watching video, so latency is an issue for me (since it could desync audio). However if you are only streaming audio to your Pi, it might be possible to increase the buffer size of the pipe between bluetoothd and bluealsa. If it works that should side step the whole scheduling issue. There is probably some ioctl for that.

@YOUN3SS
Copy link

YOUN3SS commented Sep 11, 2017

Bluez-alsa comes now out-of-the-box with Raspberry Pi Stretch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants