Remote control of mpd on a Raspberry Pi

I listen to music via a Raspberry Pi 4 running mpd, and which is connected to a Topping E30 DAC. The DAC has a remote control (RC-15A) with 13 buttons, of which 4 are unused. I control mpd via an Android app but if I need to quickly pause the music it's a bit of a faff to get the phone, unlock it, load the app and then press pause. Same for skipping tracks. I thought it might be convenient to use some of the remote's unused buttons to implement pause, prev/next track and rewinding 5 seconds into the currently playing track.

The approach I took should work with any infrared remote control. You might even use a button that's in use but doing something non-disruptive to music playback, such as the display brightness.

I read and experimented with a lot of the information on the internet about this and it wasted a lot of time as it seems most of it was written before a recent change in how IR is handled on the Pi. Also, a lot of it is based on people knowing what remote they have, which seems to be either one which came with the IR sensor, or one from a major brand (Sony, Samsung etc) where the IR protocol is known. This was not the case for the Topping remote I was interested in using.

These notes should be helpful no matter which app you want to control on the Pi.

Hardware

I have implemented this solution on the Raspberry Pi 3 and 4.

I used an IR (infrared) sensor with 1838 in the name; it seems there are several variations but they all look like they'll probably work. They're less than £2 each on eBay. My one has "VS1838B" on the back, and looks like this:

You also need 3 Dupont female to female jumper wires to connect the IR sensor to the GPIO pins on the Pi; I used 30cm long ones without any problems:

From left to right the 3 pins on the IR sensor are: Data, Ground, Power, and you want to connect them to GPIO pins 12, 6 and 1 respectively. On the Pi you can type:

$ pinout

to get a handy view of the pins. You want the red ones:

3V3 (1) (2) 5V

GPIO2 (3) (4) 5V

GPIO3 (5) (6) GND

GPIO4 (7) (8) GPIO14

GND (9) (10) GPIO15

GPIO17 (11) (12) GPIO18

GPIO27 (13) (14) GND

GPIO22 (15) (16) GPIO23

3V3 (17) (18) GPIO24

This is the remote control:

I use the large round button to toggle pause, the headphone button/line out for previous/next track respectively and the m button to play the currently playing track from the beginning. You can connect the IR sensor before proceeding with the software installation/configuration.

Software

Currently I'm using moOde on the Raspberry Pi 4, but before that I used Raspbian 10 (buster). The instructions on this page are identical for both scenarios; it's mpd which is what's playing music, and it's that which needs to be controlled using the remote. I perform most of the control of mpd using the Android app (M.A.L.P.) directly - moOde doesn't really lend itself to sensible use via a web interface on a phone/tablet. I use mpc to perform the functionality I'm binding to the unused buttons on the remote. As always with debian/Ubuntu, the official repos contain a really old, buggy version of mpd ("outdated and unsupported by this project") so get the latest one from here if you're not using moOde:

https://www.musicpd.org/download-unoff-debian/

(The official repo version of mpc is fine though.)

You need to install some tools:

$ sudo apt-get install lirc ir-keytable mpc

Configure Remote

You need a .conf file for the Topping remote control. This file is used by lircd; it contains both the protocol (how the low level pulse are interpreted) and which codes the various keys produce when pressed. I couldn't find this or anything similar on the internet, which meant that I had to use a tool to capture them. I'd read that this process was a bit flaky and I found this to be the case; it required a fair bit of trial and error. Eventually I produced the file though (I describe the process I used below); it needs to go here:

/etc/lirc/lircd.conf.d/topping.lircd.conf

begin remote

name topping

bits 32

flags SPACE_ENC|CONST_LENGTH

eps 30

aeps 100

header 8970 4566

one 501 1748

zero 501 628

ptrail 507

repeat 8974 2311

gap 108261

frequency 38000

begin codes

power 0x11EE18E7

mute 0x11EE609F

up 0x11EE629D

down 0x11EE6897

left 0x11EEE21D

right 0x11EEA857

pausetoggle 0x11EEAA55

headphones 0x11EE20DF

lineout 0x11EE02FD

fir 0x11EE2AD5

m 0x11EE0AF5

auto 0x11EE08F7

brightness 0x11EE28D7

end codes

end remote

Delete the other files in that folder.

Configure Hardware

You need to tell the Pi you're going to use the relevant GPIO pin mentioned above. I used GPIO18 (pin 12). This is done in:

/boot/config.txt

in this line:

dtoverlay=gpio-ir,gpio_in_pin=18,gpio_in_pull=up

You need to reboot after changing config.txt.

Tell lirc to use the correct device/driver with the following lines (commenting out the previous values) in:

/etc/lirc/lirc_options.conf

#driver = devinput

#device = auto

driver = default

device = /dev/lirc0

Type:

$ sudo systemctl restart lircd

whenever you change that .conf file.

Map Buttons to Actions

When you press a button on the remote you typically want something to happen. The system used for this mapping is irexec. You have good control of what happens; you can asynchronously (only!) launch any code. The mapping of a button on the remote to the command to execute is configured here:

/etc/lirc/irexec.lircrc

begin

prog = irexec

button = pausetoggle

config = mpc toggle

end

begin

prog = irexec

button = headphones

config = mpc prev

end

begin

prog = irexec

button = lineout

config = mpc next

end

begin prog = irexec button = m

config = mpc seek -00:00:05

end

There'll be an existing systemd service called irexec.service, here:

/lib/systemd/system/irexec.service

Mine looks like this (without comments):

[Unit]

Documentation=man:irexec(1)

Documentation=http://lirc.org/html/configure.html

Documentation=http://lirc.org/html/configure.html#lircrc_format

Description=Handle events from IR remotes decoded by lircd(8)

[Service]

Type=simple

ExecStart=/usr/bin/irexec /etc/lirc/irexec.lircrc

[Install]

WantedBy=multi-user.target

(Note that although the docs say "By default, no logging is done" this isn't correct and it'll spam /var/log/syslog and /var/log/daemon.log with 3 lines for each button invoked. Setting logging to error won't change this, either.)

To enable it, type:

$ sudo systemctl enable irexec.service

Whenever you change a systemd .service file you have to type:

$ sudo systemctl daemon-reload

$ sudo systemctl restart irexec.service

Make sure the following services are running:

$ sudo systemctl --state=running | grep lirc

irexec.service loaded active running Handle events from IR remotes decoded by lircd(8)

lircd.service loaded active running Flexible IR remote input/output application support

lircd.socket loaded active running lircd.socket

You should now have a working remote!

Note that you can create .conf files for more than one remote. Make sure they are all in:

/etc/lirc/lircd.conf.d/

with unique names for the buttons, and that your lircrc file - which if you remember is stored here:

/etc/lirc/irexec.lircrc

has mappings for the button to the functions you want performed.

Capturing the protocol used by the remote

I recorded the remote with:

$ sudo irrecord -n -d /dev/lirc0 ~/lircd.conf

I had to do this about 20 times. Sometimes it didn’t like the button pressing process and gave up. Sometimes it produced a file with zeros for the relevant values. When it finally produced sensible values I found, through trial and error and looking at valid files, that it had produced a second number for each key which needed to be removed. That said, I'm not sure how you'd produce a .conf file for lirc for a random remote without this.

Diagnosing problems

To test if the the IR sensor is working, connected correctly, that config.txt is configured correctly and that lirc is running, you can type:

$ cat /dev/lirc0 | hd

Then press buttons on the remote. You should see a bunch of random looking numbers for each press.

A similar test is:

$ sudo mode2 --device /dev/lirc0

which gives you data like this:

pulse 882

space 96092

pulse 9333

space 1928

pulse 793

space 96174

Testing whether the .conf is configuring button presses prior to irexec handling them is done via:

$ irw
0000000011ee629d 00 up topping
0000000011ee629d 01 up topping
0000000011ee629d 02 up topping
0000000011ee629d 00 up topping
0000000011ee629d 01 up topping
0000000011ee6897 00 down topping
0000000011eee21d 00 left topping

Another tool I used in this process:

$ sudo ir-keytable -v -t -p nec

Found device /sys/class/rc/rc0/

Parsing uevent /sys/class/rc/rc0/lirc0/ueven

/sys/class/rc/rc0/lirc0/uevent uevent MAJOR=251

/sys/class/rc/rc0/lirc0/uevent uevent MINOR=0

/sys/class/rc/rc0/lirc0/uevent uevent DEVNAME=lirc0

Input sysfs node is /sys/class/rc/rc0/input0/

Event sysfs node is /sys/class/rc/rc0/input0/event0/

Parsing uevent /sys/class/rc/rc0/input0/event0/uevent

/sys/class/rc/rc0/input0/event0/uevent uevent MAJOR=13

/sys/class/rc/rc0/input0/event0/uevent uevent MINOR=64

/sys/class/rc/rc0/input0/event0/uevent uevent DEVNAME=input/event0

Parsing uevent /sys/class/rc/rc0/uevent

/sys/class/rc/rc0/uevent uevent NAME=rc-rc6-mce

/sys/class/rc/rc0/uevent uevent DRV_NAME=gpio_ir_recv

/sys/class/rc/rc0/uevent uevent DEV_NAME=gpio_ir_recv

input device is /dev/input/event0

/sys/class/rc/rc0/protocols protocol rc-5 (disabled)

/sys/class/rc/rc0/protocols protocol nec (disabled)

/sys/class/rc/rc0/protocols protocol rc-6 (disabled)

/sys/class/rc/rc0/protocols protocol jvc (disabled)

/sys/class/rc/rc0/protocols protocol sony (disabled)

/sys/class/rc/rc0/protocols protocol rc-5-sz (disabled)

/sys/class/rc/rc0/protocols protocol sanyo (disabled)

/sys/class/rc/rc0/protocols protocol sharp (disabled)

/sys/class/rc/rc0/protocols protocol mce_kbd (disabled)

/sys/class/rc/rc0/protocols protocol xmp (disabled)

/sys/class/rc/rc0/protocols protocol imon (disabled)

/sys/class/rc/rc0/protocols protocol rc-mm (disabled)

/sys/class/rc/rc0/protocols protocol lirc (enabled)

Opening /dev/input/event0

Input Protocol version: 0x00010001

BPF protocols removed

Protocols changed to nec

Testing events. Please, press CTRL-C to abort.

6439.150112: lirc protocol(nec): scancode = 0x8855

6439.150136: event type EV_MSC(0x04): scancode = 0x8855

6439.150136: event type EV_SYN(0x00).

6440.510074: lirc protocol(nec): scancode = 0x8855

6440.510100: event type EV_MSC(0x04): scancode = 0x8855

6440.510100: event type EV_SYN(0x00).

6440.560189: lirc protocol(nec): scancode = 0x8855 repeat

6440.560213: event type EV_MSC(0x04): scancode = 0x8855

6440.560213: event type EV_SYN(0x00).

6442.200109: lirc protocol(nec): scancode = 0x8840

6442.200148: event type EV_MSC(0x04): scancode = 0x8840

6442.200148: event type EV_SYN(0x00).

6445.970063: lirc protocol(nec): scancode = 0x8855

6445.970093: event type EV_MSC(0x04): scancode = 0x8855

6445.970093: event type EV_SYN(0x00).

6446.020078: lirc protocol(nec): scancode = 0x8855 repeat

6446.020113: event type EV_MSC(0x04): scancode = 0x8855

6446.020113: event type EV_SYN(0x00).

Shows keypresses in a slightly less raw format. But after a while this gets laggy, shows the output from previous button presses as if it’s not flushing the output quickly enough. But it’s maybe useful for showing the protocols supported by the kernel, and which are enabled (nec in my case). If you were going to use a different remote perhaps you could specify them instead of nec with the -p parameter.

Notes

Don't be tempted to remove the metal over the front of the sensor - it's a Faraday cage as the sensor is susceptible to RFI.
During work on this I occasionally thought there was a problem with the sensor. It turns out that pointing the remote directly at the sensor when very close to it is actually trickier than pointing at it from further away, or even at the wall opposite. There are two reasons for this: the field of view of the sensor is rather narrow, and the remote control transmitter signal points very slightly upwards, meaning you have to point a bit lower than directly at it. At normal distances this isn't really a problem.
Hypothetically one could short the IR leads against the metal case of some equipment, instantly rebooting the Pi, if one wasn't careful.
I never used modprobe at any point.
One thing I would have liked to do would be to have the headphone/line out buttons work as prev/next when tapped, and rewind/forward when held. Maybe that's possible from an irexec config point of view, if one was proficient enough with repeat, delay and mode instructions. Unfortunately, just rewind/forward (using mpc seek -/+00:00:05, for example) runs into problems, presumably related to how mpd is buffering the track being played. You can skip 30 seconds or so into the future, but then the audio stops, I guess because it's not getting the music data quickly enough (I'm listening to flac files on an USB HD). And you can't hear any music when rewinding. I tried making the mpd buffer larger but that didn't work either.

Poldie's Blog

Saturday, 12 December 2020