-
Notifications
You must be signed in to change notification settings - Fork 189
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
Comments
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 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 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:
Restart the bluetooth and bluealsa services and you should be enjoying glitch free sound streaming from your RPi to your bluetooth device. |
I can confirm this is working even on a first generation raspberry pi. It creates a load of about 0.5. |
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. |
@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. |
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:
I'm running Stretch on a Pi Zero W. |
I am not a debian user but.... First thing you want to do on debian is Then follow the dependencies as listed here :https://github.com/Arkq/bluez-alsa#installation. Most of the time you will want install the The |
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 However, I couldn't find |
Installing |
Welp, I feel silly—I was using Stretch Lite, and this is already installed in the full-fat version. Thanks for your help regardless! |
For aac support I used, clone repo, Now you can build bluez-alsa with make |
@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. |
I started bluealsa in rc.local. I added |
@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. |
Bluez-alsa comes now out-of-the-box with Raspberry Pi Stretch. |
Any installation tutorial for compiling on raspberry pi for dependencies?
The text was updated successfully, but these errors were encountered: