The Lodge
Me, my life and I
Making XBMC work on Mint 12, with HDMI Audio Passthrough and LIRC
0I’ve got a Dell Optiplex 755 hooked up to my Yamaha amp and surround system, and it was about time XBMC was installed on it. It uses a low profile Nvidia GeForce 8400GS for VDPAU acceleration and HDMI audio. These are some rough notes I took whilst setting it up.
Follow this guide to install XBMC on Mint 12
adduser --system --home /var/lib/htpc/ htpc
vipw, change htpc shell to /bin/bash
apt-get install build-essential vim xbmc xbmc-standalone ubuntu-restricted-extras mint-meta-gnome-dvd mint-meta-codecs
Download and extract lirc-0.9.0.tar.bz2 from www.lirc.org
As I’m using a DangerousPrototypes USB IRToy, all I’m interested in is the IRMan driver
sudo apt-get install libirman-dev
./configure --prefix=/usr/ --with-driver=irman
make install
Copy the SysV startup script from a Debian package into /etc/init.d/, use update-rc.d lirc defaults to put it in all the right runlevel directories
Used my existing Hauppauge A415 remote control definition file, and put it in /etc/lirc/
Edited /etc/lirc/hardware.conf to include the following…
REMOTE_MODULES=”lirc_dev mceusb”
REMOTE_DRIVER=”irman”
REMOTE_DEVICE=”/dev/ttyACM0″
REMOTE_SOCKET=”"
REMOTE_LIRCD_CONF=”mceusb/lircd.conf.mceusb”
REMOTE_LIRCD_ARGS=”"
LOAD_MODULES=”true”
START_LIRCD=”true”
Edited /etc/lirc/lircd.conf to include the following at the end…
include “/etc/lirc/A415-HPG-KG.conf”
Ensure the lirc_dev module is loaded at boot, with echo lirc_dev >> /etc/modules
Start lirc with /etc/init.d/lirc start, and fire up irw. Press some keys on the remote to make sure it works.
Edit /etc/lightdm/lightdm.conf, ensure autologin-user=htpc, and user-session=XBMC
Reboot and bask in XBMC glory
I restored most of my XBMC settings from backups, but the audio settings were of a particular concern. This is what I use to get HDMI passthrough over a NVidia GeForce 8400GS card…
Audio Output : HDMI
Speaker Configuration : 5.1
Audio Output Device : Custom
Custom Audio Device : plughw:0,7
Passthrough output device : Custom
Custom Passthrough device : plughw:0,7
I knew the audio devices courtesy of the output from aplay -l, and some random testing with mplayer got me the results. To test it with mplayer, I just ran mplayer -fs -afm hwac3,hwdts -ao alsa:device=hw=0.7 against the name of a movie I knew had an AC3 soundtrack. Within a couple of seconds the amp was reporting a full AC3 bitstream, and surround sound was filling the living room.
Setting up the Squeezebox Receiver
059 days
I’ve got a variety of Squeezebox Receivers dotted about the house, playing synchronized music and audio on demand. Due to the lack of a remote control requirement (using the Android controller), I opted to get the receivers on their own. However, the setup procedure is highly dependent on the remote control.
To work around this, grab a copy of net-udap from https://projects.robinbowes.com/Net-UDAP/trac. Switch user to root, and then fire up ./scripts/udap_shell.pl. Switch the receivers into init mode by holding down the front panel button until it blinks red slowly. If you end up with it flashing red quickly, you’ve just reset it to factory defaults. No great loss, as the procedure is mostly the same.
Once in the UDAP shell, run ‘discover’ to scan the network for devices. After a while it will come back to the prompt, and ‘list’ will show you the discovered devices. Pick one to configure with ‘configure X’ where X is the item number.
I found that the factory installed firmware was pretty poor at doing DHCP. This may due to my lack of expertise with this equipment, or actual bugs in the software. Whatever it may be, I found the best option was to give it some static network address settings first, let it update, and then switch to DHCP.
Due to the high demands I place on my home network, I have GigE ethernet to every device. Wireless is solely for laptops and mobile phones. Consequently, the settings below are for a wired connection.
Remember… run this AS ROOT!!
=== STATIC DETAILS ===
set lan_ip_mode=0
set interface=1
set lan_gateway=172.24.32.5
set lan_network_address=172.24.32.123
set lan_subnet_mask=255.255.255.0
set squeezecenter_address=172.24.32.6
save_ip
save_data
reset
After you hit save_data, it will send the settings to the device, and the device will hopefully respond to confirm it. You should see “Raw msg:” followed by a hexadecimal dump.
The flashing LED sequence will hint that it’s not configured, but it is. If it detects a firmware update is required, it will start pulling it down and installing it. It will indicate that this is happening by rapidly flashing the front panel LED a bright white colour until the process is complete. Once it’s in a safe state, and if it’s still not indicating its presence on the network correctly, pull the power connector out and reinsert and then visit the Logitech Media Server web interface. The device should then be listed in the player drop down.
Now that the device is on the network and working, it’s time to switch it over to DHCP mode. Yet again, hold down the front panel button until it slowly flashes red. Jump into the UDAP shell again, run a discover on the network, and then configure the device that it finds.
=== DHCP DETAILS ===
set interface=1
set lan_ip_mode=1
save_ip
save_data
reset
This probably also won’t give any visual indication on the front panel. Tail the DHCP server logs to make sure it gets an IP allocated. If it does, check the Media Server web interface again.
All being well, it should then be up and running using DHCP. Happy listening!
Making OpenDAB, FEC and the Psion Wavefinder work on x64
2I’ve had a Psion Wavefinder for a while now, and it’s never really worked that well due to the rather bad combination of poorly written amateur radio related software, out of date build environments (see the previous argument), and the fact that most amateur radio enthusiasts seem to use Windows (see the first argument again)
OpenDAB has been around for a while, and it certainly seems promising. However, although it’s not an absolute requirement, the use of DAB+ is preferable, and that subsequently requires Phil Karns FEC library.
Now Phil Karn might be a genius, but he doesn’t reply to emails, and nor does he keep his build environment or OS up to date. FEC 3.0.1 is now over 4 years, doesn’t compile with modern GCC versions, and requires some massaging to make work.
Firstly, GCC no longer allows labels at the end of compound statements. This screws up dotprod.c
Next, well, I dunno what’s going on. ld chucks its guts up at the end of the build on x64 (how long has x64 been around for now?), and suggests using -fPIC. So, makefile.in was tweaked to include -fPIC in CFLAGS
I believe -m32 will do the job too, so that it’s built for x86, but hey, this works. If anyone wishes to elaborate on the pros and cons of Position Independent Code vs x86 on x64 then comment away.
In addition to this, OpenDAB supplied a patch to be applied to fec.h, as described in their documentation.
Anyway, to make life easier I created a patch. This includes the OpenDAB patch, my own patch, and a patch found at http://mmbtools.crc.ca/component/option,com_fireboard/Itemid,55/func,view/catid,7/id,178/
Just untar the standard fec-3.0.1 package, cd into it, and patch it as below. A handy one liner is also evident on this example.
bagpuss@mine:~/src/WaveFinder/fec $ wget –quiet http://ka9q.net/code/fec/fec-3.0.1.tar.bz2 ; wget –quiet http://lodge.glasgownet.com/bitsnbobs/kg_fec-3.0.1.patch ; tar -xjf fec-3.0.1.tar.bz2 ; cd fec-3.0.1/ ; patch < ../kg_fec-3.0.1.patch
patching file configure
patching file cpu_mode_port.c
patching file dotprod.c
patching file fec.h
patching file makefile.in
bagpuss@mine:~/src/WaveFinder/fec/fec-3.0.1 $
Once patched, ./configure && make && make install should have FEC up and running, and ready for OpenDAB. I have it working here on my trusty x64 Ubuntu 11.04 (actually it’s Mint 11) desktop.
Bifferboard powered weather station
083 days
So, I’ve been busy hacking bits and bobs together. End result is a VPN endpoint with a weather station attached to it. Win!
http://lodge.glasgownet.com/tech/remote-bifferboard-powered-weather-station/
Checking time over SNMP
0Not content with watching clocks drift on servers, I thought it might be prudent to keep an eye on such things. We already monitor our NTP server drift with Nagios, so why not extend it to all of our Linux servers?
The only catch here is that not all servers run the NTP server, but they do run the client. In other words, there’s no NTP port in which to poke the server on. The next best solution then is to compare the time available over SNMP with the local time of the local server (which is kept accurate by NTP)
Thankfully someone got there before me… using the setup described at http://meinit.nl/nagios-time-check-using-snmp meant that comparing the local time with NTP time was done across 50 servers in approximately 15 minutes. Nagios saves the day yet again.
Now, time to deploy an updated ntp.conf to 20 odd servers!
Recent Comments