RPi – Page 14 – The Smell of Molten Projects in the Morning

UDEV Rules for Dell AC511 USB Soundbar

A monitor sound bar seems good enough for streaming background music and suchlike, with the benefit of eliminating the external USB audio converter and reducing the cable tangle:

Dell AC511 USB Soundbar - Dell Image 318-2885r3 — Dell AC511 USB Soundbar – Dell Image 318-2885r3

That’s a Dell AC511 USB SoundBar (their choice of capitalization); I mooched the image from their description, because I cannot take a good picture of a dead-black device.

Depending on the description you read, it’s good for maybe 1.5 W, which is about all you can get directly from a USB port: 5 V at well under 500 mA. The audio output required no configuration at all: unplug the Behringer USB converter, plug this in, reboot that sucker, and It Just Worked. Sounds pretty good for as little power as it produces, too; organ music will never reach gut-pounding levels.

The far end of the bar sports a headphone output jack and a line-in jack, so apparently it can handle audio input, despite that not appearing in the online doc. Bonus!

The knob on this end spins endlessly while spitting out USB volume control events that, presumably, work seamlessly with an ordinary Windows setup. It’ll take a bit more effort with a headless Raspberry Pi.

So, we begin …

Following the usual recipe gives these results:

cat /proc/bus/input/devices
I: Bus=0003 Vendor=413c Product=a503 Version=0100
N: Name="Dell Dell AC511 USB SoundBar"
P: Phys=usb-3f980000.usb-1.5/input3
S: Sysfs=/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.5/1-1.5:1.3/0003:413C:A503.0002/input/input1
U: Uniq=
H: Handlers=kbd event1
B: PROP=0
B: EV=13
B: KEY=e0000 0 0 0
B: MSC=10

In this case, the Name field seems reasonably unique, and, seeing as how the collection of devices required to do this thing keeps growing, I renamed the old /etc/udev/rules.d/KeyPad.rules to Streamer.rules and dropped the new rule in there to keep everything together:

ATTRS{name}=="HID 13ba:0001", SYMLINK+="input/keypad"
ATTRS{idVendor}=="062a", ATTRS{idProduct}=="4101", ENV{ID_INPUT_KEYBOARD}=="1", SYMLINK+="input/keypad"

ATTRS{name}=="Dell Dell AC511 USB SoundBar", SYMLINK+="input/volume"

Load the new rule, trigger udev, and it pops up at the right spot:

sudo udevadm control --reload
sudo udevadm trigger
ll /dev/input
total 0
drwxr-xr-x 2 root root      80 Feb 23 16:35 by-id
drwxr-xr-x 2 root root      80 Feb 23 16:35 by-path
crw-rw---- 1 root input 13, 64 Feb 23 19:30 event0
crw-rw---- 1 root input 13, 65 Feb 23 19:30 event1
lrwxrwxrwx 1 root root       6 Feb 23 19:30 keypad -> event0
crw-rw---- 1 root input 13, 63 Feb 23 19:30 mice
lrwxrwxrwx 1 root root       6 Feb 23 19:30 volume -> event1

Now, to make those KEY_VOLUMEUP and KEY_VOLUMEDOWN events change the volume…

2016-03-21

Raspberry Pi Model 2: Canakit Case Reset Button Mod

Being a Linux box, a Raspberry Pi requires a tidy shutdown, but, because it uses so little power after that, I decided to forego a power switch and just blip the CPU reset line to start it up again. Canakit cases require a bit of flush-cutter hackage to accommodate a crude socket atop the RUN header:

Canakit RPi Case - reset switch - header clearance — Canakit RPi Case – reset switch – header clearance

The switch originally had three terminals, but turned out to be SPST NO with one unused pin. Flush cutters and some hot melt glue to the rescue:

Canakit RPi Case - reset switch - interior — Canakit RPi Case – reset switch – interior

The end result looks OK, modulo a few scuffs on the shiny black plastic:

Canakit RPi Case - reset switch - exterior — Canakit RPi Case – reset switch – exterior

Yeah, a clumsy swipe could wipe that actuator right off the top; we’ll see how long it lasts…

2016-03-18

Raspberry Pi Streaming Radio Player: Marginally Viable Product

The least horrible way to get events from the keypad turned out to be a simple non-blocking poll from Python’s select library, then sucking the event input queue dry; the main loop now does what might be grandiosely overstated as cooperative multitasking. Well, hey, it reads lines from mplayer’s output pipe and processes keypad events and doesn’t stall (for very long) and that’s multi enough for me.

It extracts the stream title from the ICY Info line, but I still haven’t bothered with a display. It may well turn out that this thing doesn’t need a display. The stream title will be enclosed in single quotes, but it may also contain non-escaped and non-paired single quotes (a.k.a. apostrophes): the obvious parsing strategy doesn’t work. I expect titles can contain non-escaped semicolons, too, which will kill the algorithm I’m using stone cold dead. Some try - except armor may be appropriate.

This code does not tolerate a crappy WiFi connection very well at all. I eventually replaced a long-antenna WiFi adapter with an actual Ethernet cable and all the mysterious problems at the far end of the house Went Away. Soooo this code won’t tolerate random network stream dropouts very well, either; we’ll see how poorly that plays out in practice.

The hackery to monitor / kill / restart / clean up after mplayer and its pipes come directly from seeing what failed, then whacking that mole in the least intrusive manner possible. While it would be better to wrap a nice abstract model around what mplayer is (assumed to be) doing, it’s not at all clear to me that I can build a sufficiently durable model to be worth the effort. Basically, trying to automate a program designed to be human-interactive is always a recipe for disaster.

The option for the Backspace / Del key lets you do remote debugging by editing the code to just bail out of the loop instead of shut down. Unedited, it’s a power switch: the Pi turns off all the peripherals and shuts itself down. The key_hold conditional means you must press-and-hold that button to kill the power, but don’t run this on your desktop PC, OK?

Autostarting the program requires one line in /etc/rc.local:

sudo -u pi python /home/pi/Streamer.py &

AFAICT, using cron with an @REBOOT line has timing issues with the network being available, but I can’t point to any solid evidence that hacking rc.local waits until the network is up, either. So far, so good.

I make no apologies for any of the streams; I needed streams behind all the buttons and picked stuff from Xiph’s listing. The AAC+ streams from the Public Domain Project give mplayer a bad bellyache; I think its codecs can’t handle the “+” part of AAC+.

All in all, not bad for a bit over a hundred lines of code, methinks…

More fiddling will happen, but we need some continuous experience for that; let the music roll!

The Python program as a GitHub Gist:

	from evdev import InputDevice,ecodes,KeyEvent
	import subprocess32
	import select
	import re
	import sys

	Media = {'KEY_KP7' : ['Classical',['mplayer','-playlist','http://stream2137.init7.net/listen.pls'%5D%5D,
	'KEY_KP8' : ['Jazz',['mplayer','-playlist','http://stream2138.init7.net/listen.pls'%5D%5D,
	'KEY_KP9' : ['WMHT',['mplayer','http://live.str3am.com:2070/wmht1'%5D%5D,
	'KEY_KP4' : ['Dub 1',['mplayer','-playlist','http://dir.xiph.org/listen/2645/listen.m3u'%5D%5D,
	'KEY_KP5' : ['Dub 2',['mplayer','http://streaming207.radionomy.com:80/MiamiClubMusiccom'%5D%5D,
	'KEY_KP6' : ['WAMC',['mplayer','http://pubint.ic.llnwd.net/stream/pubint_wamc'%5D%5D,
	'KEY_KP1' : ['Oldies 1',['mplayer','http://streaming304.radionomy.com:80/keepfree60s'%5D%5D,
	'KEY_KP2' : ['Oldies 2',['mplayer','http://streaming207.radionomy.com:80/1000Oldies'%5D%5D,
	'KEY_KP3' : ['Soft Rock',['mplayer','http://streaming201.radionomy.com:80/SoftRockRadio'%5D%5D,
	'KEY_KP0' : ['Smooth',['mplayer','http://streaming202.radionomy.com:80/The-Smooth-Lounge'%5D%5D
	}

	CurrentKC = 'KEY_KP7'

	Controls = {'KEY_KPSLASH' : '/',
	'KEY_KPASTERISK' : '*',
	'KEY_KPENTER' : ' ',
	'KEY_KPMINUS' : '<',
	'KEY_KPPLUS' : '>'
	}

	# set up event input and polling

	k=InputDevice('/dev/input/keypad')

	kp = select.poll()
	kp.register(k.fileno(),select.POLLIN + select.POLLPRI + select.POLLERR)

	# set up files for mplayer pipes

	lw = open('/tmp/mp.log','w') # mplayer piped output
	lr = open('/tmp/mp.log','r') # … reading that output

	# Start the default stream

	print 'Starting mplayer on',Media[CurrentKC][0]," -> ",Media[CurrentKC][-1][-1]
	p = subprocess32.Popen(Media[CurrentKC][-1],stdin=subprocess32.PIPE,stdout=lw,stderr=subprocess32.STDOUT)
	print ' … running'

	#— Play the streams

	while True:

	# pluck next line from mplayer and decode it

	text = lr.readline()
	if 'ICY Info: ' in text:
	trkinfo = text.split(';')
	for ln in trkinfo:
	if 'StreamTitle' in ln:
	trkhit = re.search(r"StreamTitle='(.*)'",ln)
	TrackName = trkhit.group(1)
	print 'Track name: ', TrackName
	break
	elif 'Exiting…' in text:
	print 'Got EOF / stream cutoff'
	print ' … killing dead mplayer'
	p.kill()
	print ' … flushing pipes'
	lw.truncate(0)
	print ' … discarding keys'
	while [] != kp.poll(0):
	kev = k.read
	print ' … restarting mplayer: ',Media[CurrentKC][0]
	p = subprocess32.Popen(Media[CurrentKC][-1],stdin=subprocess32.PIPE,stdout=lw,stderr=subprocess32.STDOUT)
	print ' … running'
	continue

	# accept pending events from keypad

	if [] != kp.poll(0):
	kev = k.read()
	for e in kev:
	if e.type == ecodes.EV_KEY:
	kc = KeyEvent(e).keycode

	if kc == 'KEY_NUMLOCK':
	continue

	# print 'Got: ',kc

	if (kc == 'KEY_BACKSPACE') and (KeyEvent(e).keystate == KeyEvent.key_hold):
	if True:
	print 'Backspace = shutdown!'
	p = subprocess32.call(['sudo','shutdown','-HP',"now"])
	else:
	print 'BS = bail from main, ssh to restart!'
	sys.exit(0)

	if KeyEvent(e).keystate != KeyEvent.key_down:
	continue

	if kc in Controls:
	print 'Control:', kc
	try:
	p.stdin.write(Controls[kc])
	except Exception as e:
	print "Can't send control: ",e
	print ' … restarting player: ',Media[CurrentKC][0]
	p = subprocess32.Popen(Media[CurrentKC][-1],stdin=subprocess32.PIPE,stdout=lw,stderr=subprocess32.STDOUT)
	print ' … running'

	if kc in Media:
	print 'Switching stream to ',Media[kc][0]," -> ",Media[kc][-1][-1]
	CurrentKC = kc
	print ' … halting player'
	try:
	p.communicate(input='q')
	except Exception as e:
	print 'Perhaps mplayer died?',e
	print ' … killing it for sure'
	p.kill()
	print ' … flushing pipes'
	lw.truncate(0)
	print ' … restarting player: ',Media[CurrentKC][0]
	p = subprocess32.Popen(Media[CurrentKC][-1],stdin=subprocess32.PIPE,stdout=lw,stderr=subprocess32.STDOUT)
	print ' … running'

	print 'Out of loop!'

view raw Streamer.py hosted with ❤ by GitHub

2016-03-11

Streaming Player: Wireless Keypad

Moving the streaming media player control panel across the Sewing Room for E-Z access:

Wireless Keypad - colored labels — Wireless Keypad – colored labels

Stipulated: garish labels that don’t fit the keys well at all.

I need more than one stream for testing; the only one that matters is Classical.

The keypad uses the same 2.4 GHz ISM band as the Raspberry Pi’s Wifi radio, which means holding a key down (which should never happen) puts a dent in mplayer’s cache fill level. Even absent that interference, the WiFi link seems more than a little iffy, probably because it’s at the far end of the house and upstairs from the router.

Other WiFi devices report that 2.4 GHz RF has trouble punching through the intervening fifty feet of hardwood floor (on the diagonal, the joists amount to a lot of wood) and multiple sets of doubled wallboard sheets; the RPi probably needs a better radio with an actual antenna. I did move the WiFi control channel away from the default used by the (relatively distant) neighbors, which seemed to improve its disposition.

2016-03-04

Raspberry Pi Streaming Radio Player: Minimum Viable Product

With the numeric keypad producing events, and the USB audio box producing sound, the next steps involve starting mplayer through Python’s subprocess interface and feeding keystrokes into it.

There’s not much to it:

Raspberry Pi Model B+ running Raspbian Jessie Lite
USB numeric keypad with sticky labels
Behringer UCA202 USB Audio Interface (replacing the Creative Labs gadget)
USB WiFi dongle (in power hog mode) on a short extension cable for better reception

As much hardware doc as you need:

RPi Streaming Player - first lashup — RPi Streaming Player – first lashup

The green plug leads off to a set of decent-quality PC speakers with far more bass drive than seems absolutely necessary in this context. The usual eBay vendor bungled an order for the adapter between the RCA line-out jacks and the 3.5 mm plug that will avoid driving the speakers from the UCA202’s headphone monitor output; I doubt that will make any audible difference. If you need an adapter with XLR female to 1/4 inch mono, let me know…

The keypad labels provide all the UI documentation there is:

Numeric Keypad - stream labels — Numeric Keypad – stream labels

The Python source code as a GitHub Gist:

	from evdev import InputDevice,ecodes,KeyEvent
	import subprocess32

	Media = {'KEY_KP7' : ['mplayer','http://relay.publicdomainproject.org:80/classical.aac'%5D,
	'KEY_KP8' : ['mplayer','http://relay.publicdomainproject.org:80/jazz_swing.aac'%5D,
	'KEY_KP9' : ['mplayer','http://live.str3am.com:2070/wmht1'%5D,
	'KEY_KP6' : ['mplayer','http://pubint.ic.llnwd.net/stream/pubint_wamc'%5D,
	'KEY_KP1' : ['mplayer','-playlist','http://dir.xiph.org/listen/5423257/listen.m3u'%5D,
	'KEY_KP2' : ['mplayer','-playlist','http://dir.xiph.org/listen/5197460/listen.m3u'%5D,
	'KEY_KP3' : ['mplayer','-playlist','http://dir.xiph.org/listen/5372471/listen.m3u'%5D,
	'KEY_KP0' : ['mplayer','-playlist','http://dir.xiph.org/listen/5420157/listen.m3u'%5D
	}

	Controls = {'KEY_KPSLASH' : '/',
	'KEY_KPASTERISK' : '*',
	'KEY_KPDOT' : ' '
	}

	k=InputDevice('/dev/input/keypad')

	print 'Starting mplayer'
	p = subprocess32.Popen(Media['KEY_KP7'],stdin=subprocess32.PIPE)
	print ' … running'

	for e in k.read_loop():
	if (e.type == ecodes.EV_KEY) and (KeyEvent(e).keystate == 1):

	kc = KeyEvent(e).keycode

	if kc == 'KEY_NUMLOCK':
	continue

	print "Got: ",kc

	if kc == 'KEY_BACKSPACE':
	print 'Backspace = shutdown!'
	p = subprocess32.call(['sudo','halt'])
	break

	if kc in Controls:
	print 'Control:', kc
	p.stdin.write(Controls[kc])

	if kc in Media:
	print 'Switching stream to ',Media[kc]
	print ' … halting'
	p.communicate(input='q')
	print ' … restarting'
	p = subprocess32.Popen(Media[kc],stdin=subprocess32.PIPE)
	print ' … running'

	print "Out of loop!"

view raw StreamingPlayer.py hosted with ❤ by GitHub

The Media dictionary relates keycodes with the command line parameters required to fire mplayer at the streaming stations. With that running, the Controls dictionary turns keycodes into mplayer keyboard controls.

There’s no display: you have no idea what’s going on. I must start the program manually through an ssh session and can watch mplayer‘s console output.

Poking the Halt button forcibly halts the RPi, after which you squeeze the Reset button to reboot the thing. There’s no indication that it’s running, other than sound coming out of the speakers, and no way to tell it fell of the rails other than through the ssh session.

The loop blocks on events, so it can’t also extract stream titles from the (not yet implemented) mplayer stdout pipe / file and paste them on the (missing) display; that’s gotta go.

There’s a lot not to like about all that, of course, but it’s in the tradition of getting something working to discover how it fails and, in this case, how it sounds, which is even more important.

2016-03-03

Raspberry Pi: USB Keypad Via evdev

The general idea is to use keystrokes plucked from a cheap numeric keypad to control mplayer, with the intent of replacing some defunct CD players and radios and suchlike. The keypads look about like you’d expect:

The keypad layouts are, of course, slightly different (19 vs 18 keys!) and they behave differently with regard to their NumLock state, but at least they produce the same scancodes for the corresponding keys. The black (wired) keypad has a 000 button that sends three 0 events in quick succession, which isn’t particularly useful in this application.

With the appropriate udev rule in full effect, this Python program chews its way through incoming events and reports only the key-down events that will eventually be useful:

	from evdev import InputDevice,ecodes,KeyEvent
	k=InputDevice('/dev/input/keypad')
	for e in k.read_loop():
	if (e.type == ecodes.EV_KEY) and (KeyEvent(e).keystate == 1):
	if (KeyEvent(e).keycode == 'KEY_NUMLOCK'):
	continue # we don't care about the NumLock state
	else:
	print KeyEvent(e).scancode, KeyEvent(e).keycode

view raw KeyPad Events.py hosted with ❤ by GitHub

Pressing the keys on the white keypad in an obvious sequence produces the expected result:

82 KEY_KP0
79 KEY_KP1
80 KEY_KP2
81 KEY_KP3
75 KEY_KP4
76 KEY_KP5
77 KEY_KP6
71 KEY_KP7
72 KEY_KP8
73 KEY_KP9
98 KEY_KPSLASH
55 KEY_KPASTERISK
14 KEY_BACKSPACE
74 KEY_KPMINUS
78 KEY_KPPLUS
96 KEY_KPENTER
83 KEY_KPDOT

Observations

KeyEvent(e).keycode is a string: 'KEY_KP0'
e.type is numeric, so just compare against evcodes.EV_KEY
KeyEvent(e).scancode is the numeric key identifier
KeyEvent(e).keystate = 1 for the initial press
Those KeyEvent(e).key_down/up/hold values don’t change

If you can type KEY_KP0 correctly, wrapping it in quotes isn’t such a big stretch, so I don’t see much point to running scancodes through ecodes.KEY[KeyEvent(e).scancode] just to compare the enumerations.

I’m surely missing something Pythonic, but I don’t get the point of attaching key_down/up/hold constants to the key event class. I suppose that accounts for changed numeric values inside inherited classes, but … sheesh.

Anyhow, that loop looks like a good starting point.

2016-03-02

Improving Avahi Startup Speed

At least on my network, disabling the IPv6 functions makes Avahi start up faster. You do that by tweaking the obvious IPV6 line in /etc/avahi/avahi-daemon.conf:

use-ipv4=yes
use-ipv6=no

It’s also useful to disable power management in the USB WiFi dongle by adding /etc/modprobe.d/8192cu.conf:

# Disable power saving
options 8192cu rtw_power_mgnt=0 rtw_enusbss=0

2016-02-19