Tag Archives: htpc


Random update, DIY Wirelesss Guitar Hero

Yikes, it’s been nearly a month since I updated this last. A lot has happened since then… but I’ll skip to some more recent things.

David is a Californian, as of last Tuesday! He kept busy buying furniture and waiting in line at the DMV, but I did manage to see him at my birthday dinner last week. He and I cooked dinner last night: Ahi tuna steaks with a southwestern papaya/pineapple/habanero salsa, and a habanero pilaf dish on the side. Mmm.

I’ve been in a tinkery mood lately. I recently replaced my old noisy analog audio routing system (an A/B box and about 30 feet of cable) with a shiny new all-digital solution. I have a USB sound adaptor near the TV. It gets digital audio from the TV, and outputs directly to the speakers. It’s attached to the computer in my nearby cabinet, which does all the mixing in software.

After trying several software solutions for the audio mixing problem, I’ve settled on PulseAudio with a trivial extension module that routes audio from the TV input directly to the speaker output. I can now play TV audio, music from MPD, networked audio from my laptop, or any combination of the above. Latency hasn’t been noticeable, though I haven’t done any measurements yet.

The computer in my closet (mini-navi) has gone through a couple more revisions. In order to support audio mixing and icecast, I upgraded it from an NSLU2 to my old 700 MHz PIII laptop. This gave me the performance I needed, but that old laptop has some really serious Cardbus interrupt routing issues that prevented me from getting USB 2.0 working properly. After all that frustration, I splurged a little and got a mini-itx board with a 1 GHz Via C3. I love the novelty of mounting a motherboard with wood screws.

Before dinner with David last night, we decided to finally buy Guitar Hero. There had always been talk of building a wireless guitar controller

January 2006 Update


It’s easy for me to see Fyre as a ‘dead’ project these days- the existing codebase was declared ‘done’, and we moved on to a new architecture dubbed Fyre 2.0. In some ways this rewrite has suffered from second system effect, and the code hasn’t been touched in a while. But, I think we all agreed this was necessary. Fyre 1.0 really was a great release, and it really did everything we felt it should do considering the project’s scope.

Anyway, it’s really heartwarming when I come across an enthusiastic user of Fyre on the interweb, who’s posted some renderings of their own. It’s even cooler to find someone who’s implemented their own Distributed Chaotic Image Renderer after being inspired by Fyre.

Now that Firefox 1.5 is commonplace, I might as well mention my old Javascript De Jong renderer. It’s a great example of why the <canvas> element is largely orthogonal to SVG.

Home Theater

My traditional method of playing DVDs at home would be to boot up my HTPC and play them via Freevo. In concept this was great, but the picture quality left much to be desired- lots of horizontal ‘wiggle’ due to noisy sync signals from my video card’s component out, and the video was getting scaled at least twice.

Yesterday, while wandering the shopping megaplex that is Santana Row, I finally picked up a hardware DVD player: An LG LDA-511, on sale for $110 after rebate. I’m just blown away by how much hardware you get for that price these days: slot loading drive, HDMI output, upscaling to any HDTV resolution, DivX/MPEG4/JPEG/MP3/WMA playback, memory card slots… The picture quality is great, and it will even play a lot of music and video directly off of my existing DVD-R discs. My one complaint so far is that the memory card reader is excruciatingly slow. It’s a good thing I doubt I’ll ever have a use for that feature.


I came across the Django project recently. This is an incredibly spiffy mod_python-friendly web framework, which includes a template system and a rather cute object-relational mapper. Since I’ve been wanting to get CIA‘s web frontend away from Twisted and onto mod_python for a while now, this looks like a great opportunity to simultaneously do away with Nouvelle.

So, I’ve started a branch for what’s sure to be a heavy-handed hack and slash partial rewrite. The biggest issue with splitting the HTTP frontend into multiple mod_python processes, however, is the ruleset storage. Currently, CIA just loads all rulesets from the database on startup, compiles them a bit, then scans them linearly every time a message is delivered. This is both RAM-hungry (about 8MB) and very CPU inefficient. My current strategy is to actually compile the rulesets into an SQL table such that the slowest and least scalable aspects of message filtering can all be done efficiently within the SQL server.