I wanted to use a Raspberry Pi to act as a Bluetooth audio receiver or my Hi-Fi so that I could connect a phone/tablet easily to some proper speakers wirelessly. Rather than reinventing the wheel 'kmonkey' has already achieved most of what I set out to do over here; check this out first.
The only issue now is the manual intervention needed to connect up a new Bluetooth source to the output sink. I initially created a simple bash script to poll pulseaudio (every 5 seconds) and run the necessary commands as and when a new device is connected. You can see the script here and all the pertinent commands are explained over in kmonkey's blog. This is all good, but will need to be run manually using something like,
This is a bit rubbish and you'll be pleased to know there is a better way to get this done, UDEV!
Over at the Raspbery Pi forums there's some discussion on using UDEV scripts to automate this process entirely. Initially I had had some issues with their scripts and was experiencing source disconnects after ~20 seconds of playback. Another problem was that a new incoming Bluetooth connection would scupper the currently connected device which may be quite undesirable (e.g. if anyone else in the house uses another device with your setup as my wife does).
I've re-factored my original methodology into the following UDEV script at the bottom of this post. The major improvement here is that we no longer interfere with any currently running Bluetooth playback and we also add the ability to easily specify a user to run our commands as. You could always use the 'Pi' user (or your own user account), but I don't like giving random background processes my full privileges. You can create such an unprivileged user like so,
To trigger the udev script when a new device connects create (or modify) an even handler in /etc/udev/rules.d/99-input.rules adding the following content rules,
We're now almost running a fully headless A2DP receiver, except one problem, the 20 second cut outs. It turns out this happens because pulseaudio times out playback for users if they are not active, like our 'btaudio' user. Back at the forums some suggest running pulse as a system process, but before heading down that route you really should read this information. Instead we just need to disable timeouts by adding a line in '/etc/pulse/client.conf' to read,
Enjoy!
OK, not quite. For reasons not yet understood this is still not working from a cold start as I would like it to. Instead it begins working only after a user has logged in, even if that user immediately logs out again. I run my setup headless and have to login once via SSH to kick things off. Once I've done that it runs seamlessly for weeks at a time. Suggestions welcome.
The only issue now is the manual intervention needed to connect up a new Bluetooth source to the output sink. I initially created a simple bash script to poll pulseaudio (every 5 seconds) and run the necessary commands as and when a new device is connected. You can see the script here and all the pertinent commands are explained over in kmonkey's blog. This is all good, but will need to be run manually using something like,
# nohup ./bt_audio_attach &
This is a bit rubbish and you'll be pleased to know there is a better way to get this done, UDEV!
Over at the Raspbery Pi forums there's some discussion on using UDEV scripts to automate this process entirely. Initially I had had some issues with their scripts and was experiencing source disconnects after ~20 seconds of playback. Another problem was that a new incoming Bluetooth connection would scupper the currently connected device which may be quite undesirable (e.g. if anyone else in the house uses another device with your setup as my wife does).
I've re-factored my original methodology into the following UDEV script at the bottom of this post. The major improvement here is that we no longer interfere with any currently running Bluetooth playback and we also add the ability to easily specify a user to run our commands as. You could always use the 'Pi' user (or your own user account), but I don't like giving random background processes my full privileges. You can create such an unprivileged user like so,
# useradd -rMN -g nogroup -G lp,audio btaudio
To trigger the udev script when a new device connects create (or modify) an even handler in /etc/udev/rules.d/99-input.rules adding the following content rules,
We're now almost running a fully headless A2DP receiver, except one problem, the 20 second cut outs. It turns out this happens because pulseaudio times out playback for users if they are not active, like our 'btaudio' user. Back at the forums some suggest running pulse as a system process, but before heading down that route you really should read this information. Instead we just need to disable timeouts by adding a line in '/etc/pulse/client.conf' to read,
extra-arguments = --exit-idle-time=-1 --log-target=syslog
Enjoy!
OK, not quite. For reasons not yet understood this is still not working from a cold start as I would like it to. Instead it begins working only after a user has logged in, even if that user immediately logs out again. I run my setup headless and have to login once via SSH to kick things off. Once I've done that it runs seamlessly for weeks at a time. Suggestions welcome.
Thank you - I couldn't get the script on the Pi forums to function but yours worked beautifully - I might add that streaming would only work properly if the pi is logged in.
ReplyDeleteI total agree with you in this point. Happy to see you here !
DeleteThanks a lot, same as user below!!!
ReplyDeleteThank you, works great!
ReplyDeleteI mostly got streaming over bluetooth working on the Pi but ran into the problem of pulseaudio stopping after about 20 seconds. Your post solved this for me. Thanks very much. You can get the Pi to auto login by editing the /etc/inittab file and replacing the line
ReplyDelete1:2345:respawn:/sbin/getty 115200 tty1
with
1:2345:respawn:/bin/login -f pi tty1 /dev/tty1 2>&1
I already have
ReplyDeleteSUBSYSTEM=="input", GROUP="input", MODE="0660"
in etc/udev/rules.d/99-input.rules
Is it right to add the line
SUBSYSTEM="input", GROUP="input", MODE="0660"?
Notice the difference in = vs ==. Which is right?
How about supplying an image or zip of the configs, so we don't have to repeat all the steps?
ReplyDeleteConfiguration insightful, you would be hit with a colossal shower as the point of convergence in the room and I think it would look like gracious they included a shower in here.
ReplyDeleteHow about supplying an image or zip of the configs, so we don't have to repeat all the steps?
ReplyDelete??
Hey, I do think the thing is that the "SWITCH" on the Aerial Wireless bluetooth Modem will be on fasten function, or maybe DOWN. It really is merely form AUDIO/MIC jack.
ReplyDeleteSetup insightful new, you would be strike that has a heavy shower since the level connected with convergence inside the place and also I believe it will look like thoughtful they bundled any shower within right here.
ReplyDeleteSetup informative, using attack using a colossal bath since the point of convergence in the place along with I believe it might seem like nice many people bundled a bath with right here.
ReplyDeleteI mostly got alive over bluetooth alive on the Pi but ran into the botheration of pulseaudio endlessly afterwards about 20 seconds. Your column apparent this for me. Thanks actual much. You can get the Pi to auto login by alteration the /etc/inittab book and replacing the line
ReplyDeleteThank you, works great! I have a question: How about supplying an image or zip of the configs, so we don't have to repeat all the steps?
ReplyDeleteI love your post, it really good and interesting.
ReplyDeleteThanks a lot for sharing us this article. Great job.
ReplyDeleteLine 17: should be "RUNNING", not "RUNIING" - right?
ReplyDeleteYeah, I would imagine so, but do check that it is my mistake and not pactl's by checking the real output :)
DeleteThis comment has been removed by a blog administrator.
ReplyDelete