Thursday, February 8, 2007

Using lirc with audio_alsa

There are some pages on the lirc site
that show you how to connect an IR receiver diode to the Microphone port of your sound card. You need to get +5V from somewhere and there is a suggestion to wire a 0.6V diode across the output to limit the voltage swing. I did all that, but had a lot of trouble working out how to get it to go. Most of the examples on this page did not work. I'm using the internal sound card of a T40 laptop (well its the base of a T40). I tried
arecord -D hw:# -c1 -r8000 -f U8
I could not seem to find a hw:# or hw:#,# number that would work at all. If I left off the -D hw:# entirely it would work. Since I couldn't seem to work out the hardware number, attempting the next bit:

irrecord -d hw:1,0 file


was futile. After a lot of going round in circles, I discovered that plughw:0,0 would work as a device name:

irrecord -d plughw:0,0 file

But there was still something else wrong, and I ended up applying this patch that makes sampling take place in 16 bit mode rather than 8 bit mode. The only mention of it is here. The patch as it is on that web page would not apply cleanly to the current hw_audi_alsa.c file, so I ended up working out the changes by hand.

Now I had versions of irrecord and lircd that actually seemed to work. Initially I left off the 0.6V diode across the IR diode output, but I had a lot better results with it connected. Still there are certain brands of remotes that are virtually impossible to learn from.

One big thing I learned is that if you use lirc with the audio_alsa (ie. Microphone input) you don't need any special kernel modules ... as are mentioned in the instructions for other IR adapters. lircd will create that /dev/lircd socket and then other programs communicate through it.... such as irw.

I also played around with different sample rates:

lircd -d plughw:0,0@48000 /etc/lircd.conf

lircd -d plughw:0,0@11024 /etc/lircd.conf

48000 probably works better. But trying to work out the ideal capture volume is difficult (NB: I found that the Mic volume control in alsamixer didn't actually do much. Had to press Tab to get to the capture volume and control that). And also, certain remotes seemed to work better. Sony remotes were definately more understandable. The xbox remote was one of the hardest.

So far, I'm still experimenting with this as it doesn't seem to work very reliably.

Speedtouch USB modem on OpenWRT RC6

I've been happily using an Alcatel Speedtouch USB modem connected to an ASUS WL-HDD running OpenWRT RC4 as my 'ADSL router'. This has worked great. I can't remember whether there were official packages for the speedtouch in RC4, but somehow I got them and had it working (I think I had to trawl the forums a bit). Anyway, RC6 has some nice QoS stuff in it, so I thought I'd upgrade. However, it doesn't look like anyone has redone the speedtouch package for RC6. I ended up backing up my RC4 install , installing RC6 and then manually copying some of the old files from RC4 in order to get it to work.

One nice thing is that when you do an 'upgrade' by reflashing, all your nvram settings stay. I did a 'micro' install this time


RC6 ipkg packages to install:

kmod-usb-core
kmod-usb-ohci
ppp
libgcc
libpthread


Files you need from RC4

/sbin/ifup.speedtouch
/etc/init.d/S30speedtouch
/lib/modules/2.4.30/n_hdlc.o
/lib/modules/2.4.30/ppp_synctty.o
/usr/lib/speedtouch/firmware/mgmt.o.gz
/usr/sbin/pppoa3
/usr/sbin/modem_run

I had to edit /etc/init.d/S05nvram and added this to the end:

nvram set wan_ifname=ppp0

Also take a good look at the /etc/init.d/S35firewall script. It initially opened up access pretty wide by virtue of the ppp0 interface not being recognised as the outward facing interface.

I think thats pretty much it. If you're troubleshooting, the S30speedtouch does the modem_run bit that loads the firmware from the mgmt.o.gz file into the Speedtouch. The actual ppp link is brought up via the S40network script. The speedtouch is the wan interface effectively. That hack to the wan_ifname nvram setting is because it tends to get overridden by the S05nvram script during the boot. So the S40network script ends up doing a "ifup wan" and then that will call /sbin/ifup.speedtouch (because wan_proto=speedtouch) which kicks off pppd with the args required to bring up the pppoatm link (this is for PPP over ATM style ADSL).