Friday, 18 January 2013

Raspberry Pi A2DP Bluetooth Audio Receiver

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,

# 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.

Tuesday, 1 January 2013

Blocking Adverts from the Roku Menu

UPDATE: 18 May 2013 - A new firmware (v5) has changed the way ads are handled on the Roku such that this guide is no longer relevant. 

Roku are are a pretty neat little media streaming box but one thing that I think lets them down are the trashy and mostly irrelevant adverts on the home page. Wouldn't it be great if you could get rid of these?

The ads are served by the third party ad platform, ZEDO. You can block the ads from displaying by simply blocking this domain entirely or by being more targeted and blocking the specific sub-domain serving the Roku ads. A TCPDUMP of my Roku shows that the ad images currently come from 'd7.zedo.com' (although this may change).

I block them by adding a custom DNS record for this sub-domain to my home router pointing to the loopback address (127.0.0.1). There are or course many other ways you could do this, but the best way will largely depend on your own set-up and resources.