Logic Supply once again has stock of the Broadcom Crystal HD cards, now down to $55.00, and with a $10 off coupon code, XBMC10. Get ‘em while they’re hot! (At least, I think the coupon code is still good…). I’ve been too busy to poke at mine for a few days, but I’ve got several of the newer bcm970015 part in hand now that I need to start working on support for in the crystalhd driver…
Feb 10 2010
MythTV 0.23 and Arclight
Been meaning to post this for a few days now… I made the jump over to pre-0.23 MythTV svn builds at home about a week ago now, and along with it, picked up a copy of Robert McNamara’s excellent new Arclight theme, which from the link there, you can see is now in MythTV’s svn repo, despite Robert’s earlier plan to release the theme under a Creative Commons no modification license and a need to purchase a font (Frutiger) for use with it. Its been released by Robert as GPL, and reworked to use freely redistributable fonts, League Gothic and CartoGothic Std (both included in the MythTV svn repo, and will likely be installed for you as part of the mythtv-themes package(s) for the various Linux distros — it will be for Fedora, I’ve started building svn trunk packages for Fedora 13 (current rawhide). I haven’t seen a side-by-side comparison of screen shots with Frutiger vs. the Gothic stand-ins, but it looked damned good to me in both the earlier screenshots I’d seen with Frutiger, and as it exists now on my main MythTV frontend at home.
Jan 29 2010
Car maintenance
I’m not one for buying a new new car. Been there, done that, they cost too damned much. So the past four vehicles we’ve bought have been used. You can get a helluva lot more car for the money, but do run the risk of getting a vehicle that hasn’t been particularly well maintained or has some hidden defect. Fortunately, for the most part, that hasn’t been the case with any of the used cars we’ve bought. However, with my latest car purchase just over a year ago, a 2004 Volvo S60 R, there’s been a fair amount of maintenance and/or repair (~$3k worth), and it wasn’t until a few weeks after I got the car home that I realized it had two different pairs of tires front and back, after the front left one developed a leak that only seems to leak when its really cold out. Made it out of last winter and into summer, and didn’t have any problems with the tire for a good 10 months. Well, back to January again, and its been well below freezing quite a few days of late. One day earlier this month, I drove around with the tire a lot lower on air than I realized, and I’ve either damaged the tire or the rim, because the car just doesn’t ride as smooth as it should right now, due to excess vibration/bumpiness/whatever from the front left. The tire needed replacing anyway, so I’m starting with a set of new tires first, and hoping the rim is just fine. The stock tires on my car are Pirelli P-Zero Rosso high-performance summer tires. Not the greatest thing to drive around New England in, especially in the winter. I’m too cheap or don’t care *that* much about performance such that I’d buy a set of winter tires *and* a set of summer tires, so I just bought the highest rated all-season high-performance tires that will fit my car from Tire Rack, the Continental ExtremeContact DWS, which also happen to be quite reasonably priced. Here’s hoping I like ‘em. Can’t be worse than the air-losing, not-much-tread left Toyo pair on the front end of my car right now, at least. (The rear pair is actually in pretty good shape, and I plan to keep those, just in case…).
The car is also due for yearly MA vehicle inspection by the end of the month. One tiny problem is a crack in the windshield, which is grounds for a failed inspection. Fortunately, windshield replacement in MA is 100% covered by insurance, doesn’t impact deductible, etc., and my insurance guy referred me to Riverside Glass, who says they can get me a new windshield installed later today, meaning I should still be able to get my inspection done before the end of the month, and not have to drive around in an illicit vehicle (like my wife has been doing for the past month… she really needs to get her car in for inspection like yesterday, and there’s no reason it won’t pass, she’s just … busy, or something…) 
Still need to put my iMIV iPod adapter back in the car too. I yanked it and shipped it back to the mfg a few months back due to it constantly ceasing to work in its so-called “Advanced” mode, where it displays track info on the stock stereo, allows iPod control from the stereo, etc. It kept wussing out on me, and only working in standard mode, where you have to hit play/pause/skip directly on the iPod. Less than ideal when the iPod is stashed away in the glovebox. Anyway, they couldn’t find anything wrong with it. I have some theories about funky id3 tags in some of my music possibly throwing the thing for a loop. Either way, getting tired of the same four CDs in my changer, will be nice to have the iPod back in action in the car.
Jan 26 2010
Crystal HD vs. nVidia VDPAU decoding/playback
I’ve been doing a fair amount of experimenting, mostly using xbmc’s svn trunk code, comparing the playback quality, cpu usage, codec support, etc. of both Broadcom Crystal HD-based decoding and nVidia VDPAU-based decoding of assorted video files I’ve got around the house. Now, open-source crystalhd support under Linux is quite new, as some of you may know. But the chip and driver have actually been around for quite some time, lurking in assorted set top boxes, if I understand correctly. The chip and driver, so far, seem pretty robust (not surprising, if they have indeed been in set top boxes for some time now), and definitely highly capable. nVidia’s graphics cards have been able to do video decoding for probably at least as long, but until a year ago or so, only the Windows drivers supported that functionality, so VDPAU is relatively new as well, but its usage is a bit more established than the crystalhd in the world of open-source. (Note, of course, that while there’s an open-source libvdpau, the only way to provide a working decoder backend for libvdpau is via binary-only drivers from nVidia or S3, the latter of which I know nothing about, so for the open-source purists, crystalhd is a win here).
The question many people have asked me (on mythtv irc and mailing lists, primarily), is ‘how does it compare to VDPAU?’. Well, it compares quite favorably. I’ve got a development box with an nVidia Quadro FX 1700 and a Broadcom Crystal HD card in it that I’ve been poking at the past few nights. For fully-compliant h.264 streams, there’s little or no difference in the quality of the decoders, with maybe a *slight* (and possibly only perceived and subjective) edge to the Crystal HD decoder. They’re both quite good. Like, you can’t tell this is a desktop computer playing back the video and not a commercial blu-ray player good. At the moment, less-than-100%-spec-compliant h.264 clips tend to give the Crystal HD fits, while they play fine using VDPAU. However, most of that is software-side, and can/will be remedied as development progresses.
As for mpeg2 (aka High-Definition TV in the US), the Crystal HD does support that as well, but most work has been focused on h.264 to date. The mpeg2 decoding via Crystal HD in xbmc isn’t quite there yet, but Scott has been working on it. A few days ago, 1080i mpeg2 content had a nasty green cast to it, along with alternating light and dark stripes. The green cast is gone now, but the stripes persist — it also looks like either fields are playing out of order or being drawn in not quite the right locations, visually manifesting as the picture oscillating up and down a pixel or two. Both 720p and 1080i lose sync after a bit as well, and then the player thrashes about trying to get them back in sync (or something). But they’re known issues, and progress is being made.
I have to add this data point though: while playing back some 1080p h.264 video decoded by the Crystal HD this past weekend, my wife said “wow, that looks so good! why does it look so good? I don’t remember it looking that good before!” (more or less).
So why should you choose one over the other? Depends on a few things… If you’re in the camp that is morally opposed to binary-only software, such as the nVidia graphics driver, the Crystal HD route is far less morally reprehensible. It *does* require use of a binary-only firmware image that must be loaded onto the card, but otherwise, the driver and interface library are 100% open-source (GPL driver, LGPL library). The driver is in the Linux kernel staging tree, and the library is making its way into Linux distributions. The Crystal HD isn’t dependent on any particular graphics chipset either. I’ve got an Intel X3100 graphics Lenovo ThinkPad T61 and an Intel GMA950 Mac Mini, neither of which I could replace the graphics chipset in. Both have mini PCIe slots though. And now both can play back 1080p h.264 using the Crystal HD, whereas before, notsomuch. Note however, that there are higher cpu and memory requirements for using the Crystal HD to decode video than for VDPAU. This is the down side of it not being tied to a particular graphics chipset. Because its a separate device, there is occasional format conversion (rgb to yuv, nv12 to yv12, etc., etc) and buffer copying (from Crystal HD to graphics card) that has to be done, rather than everything occurring strictly within the graphics chip. That said, even a lowly 1GHz AppleTV with 256MB of RAM can play back 1080p h.264 with a Crystal HD (its just pretty close to maxed out). Chances of having a PCI express-capable chipset with a CPU slower than that are minimal. Single-core Atom systems, particularly in netbooks, are one of the main targets for the Crystal HD.
Back to the hardware for a moment… To make room for the Crystal HD in my T61, I yanked the worthless-under-Linux Intel TurboMemory card. In the Mac Mini, I yanked the wifi card, since I have wired GbE to it. If you have a system with an available PCIe slot, its probably easier to simply drop an nVidia graphics card in — partially because the Crystal HD is only generally available in a mini PCIe card format right now, meaning you’d need an adapter to use one in a PCI express system w/o a mini PCIe socket (but these do exist). Remember the above-mentioned development system w/the Quadro FX 1700 in it? Its actually a tower with no mini PCIe socket — I have a PCIe x1 Crystal HD card courtesy of Broadcom, its just not available anywhere on the open market at this time. They’d like for it to be, as well as an expresscard variant (for laptops without an available internal mini PCIe socket to spare), but the mini PCIe is likely to be the one most in demand by far, so only time (and market conditions) will tell what options become available.
Jan 22 2010
Elgato Turbo.264 HD and Linux
Some time ago, I picked up an Elgato Turbo.264 HD stick to play with. At the very least, its something I can use with my Mac computers under Mac OS X. In the long run, I thought it might be fun to poke at it under Linux and see if it couldn’t be made to work there. Today in #mythtv-users on freenode, Devin Heitmueller pointed me at an already-under-development libcrusher264 ffmpeg patch for it. Very cool. The HD variant I have isn’t yet supported, but its a great start. I’ll have to poke at that more some day. In the mean time, it works pretty damned well with my 17″ MacBook Pro under Mac OS X, and I’ve got way too many other things to work on with higher priority anyway…
Jan 22 2010
Crystal HD and xbmc
They work fantastically well together. Scott Davilla, who is the one that got the ball rolling on open-sourcing the crystalhd driver and library and brought me into the fold, has done an outstanding job with the xbmc development trunk code, adding support for offloading decoding to the crystalhd. I grabbed the Big Buck Bunny 1080p h.264 clip and threw it at a build of today’s xbmc on an x86_64 Fedora 12 install on my Lenovo ThinkPad T61 (sporting a Core 2 Duo processor at 2.2GHz and Intel X3100 graphics), and the system hardly broke a sweat, topping out at 39% cpu usage, with absolutely flawless decoding and perfectly smooth playback. Juxtapose this with mplayer operating on the same file, pegging one cpu core, with obvious dropped frames, stuttering, etc. Good stuff.
Jan 21 2010
Crystal HD xine plugin
Managed to hack together a xine-lib-1.2 hg development tip rpm for Fedora 12 last night. After getting that installed on my ThinkPad T61, the xine crystalhd decoder plugin built without a problem. Installed it, and let xine have at it with an h.264 clip from my Hauppauge HD PVR. Lo and behold, it works! Not exactly perfect just yet — there was a xine process spinning at 120% in top during playback and the video didn’t quite look smooth — but it did play back the video, decoded by the crystalhd. More poking later. Need to take a closer look at xbmc’s crystalhd support too.
Jan 20 2010
SoundGraph iMON (and Antec Veris) LCD/VFD/IR devices
Just a quick summary on the state of things with the SoundGraph iMON and Antec Veris LCD/VFD/IR devices, integrated into many Home Theater PC cases these days (as well as available as additions via 5.25″ bays in existing cases)…
So to start out, let it be known that there are three main classes of SoundGraph iMON devices out there these days:
- Really old stuff
- Device ID 0xffdc stuff
- Current stuff
The really old stuff isn’t particularly common. You can’t buy it new anywhere, so far as I know, and I’ve only ever run into a single person that actually *had* some of the really old stuff (by way of a bug report in Red Hat’s bugzilla). Its all usb-based, with the following device IDs (from the lirc_imon Linux kernel driver):
/* TriGem iMON (IR only) -- TG_iMON.inf */
{ USB_DEVICE(0x0aa8, 0x8001) },
/* SoundGraph iMON (IR only) -- sg_imon.inf */
{ USB_DEVICE(0x04e8, 0xff30) },
/* SoundGraph iMON VFD (IR & VFD) -- iMON_VFD.inf */
{ USB_DEVICE(0x0aa8, 0xffda) },
/* SoundGraph iMON SS (IR & VFD) -- iMON_SS.inf */
{ USB_DEVICE(0x15c2, 0xffda) },
The infrared receiver in these devices passes raw IR signals through to the driver, which the driver then passes to userspace (to the lirc daemon, lircd), which interprets them and maps them to keys, pretty much just like how most other IR receivers interoperate with lircd.
Now, the device ID 0xffdc (more on that in a sec) and the current stuff behave much differently. These devices do NOT pass raw IR signals, they have onboard IR signal decoders, which convert the received IR signals from raw IR to a unique hex code that represents a specific key. Historically, these devices have also been supported by the lirc_imon Linux kernel driver, and instead of passing raw IR signals to lircd, we simply send the hex code, which lircd would happily map to a key. However, the code paths traveled in lirc_imon by the really old stuff and the newer onboard decode devices diverge quite a bit, and with the onboard decode receivers, we can skip the lircd part entirely, and map the keys in the driver itself, since the raw IR signal has already been decoded.
Enter the imon Linux kernel input layer driver. I’ve split support for the onboard decode devices out of the lirc_imon driver and into a new driver, simply called ‘imon’. The decoded IR signal hex values are all mapped inside the kernel to standard input layer keys, so the driver works “out of the box”, without having to configure anything in userspace (such as lircd, which needs a config file mapping codes to keys, in addition to having to install and run the lircd program itself). I’ve submitted this driver for inclusion in the linux kernel, though my v2 submission (following v1 review fixes, cleanups and refactoring) seems to be stalled at the moment.
Back to the device ID 0xffdc stuff for a second… This snippet from the imon driver begins to explain the problem:
/*
* Several devices with this same device ID, all use iMON_PAD.inf
* SoundGraph iMON PAD (IR & VFD)
* SoundGraph iMON PAD (IR & LCD)
* SoundGraph iMON Knob (IR only)
*/
{ USB_DEVICE(0x15c2, 0xffdc) },
As you can see, the *exact* same device ID was used for several different devices, and to date, we don’t have any way in the Linux driver to differentiate between them. This is problematic, because we need to use different display write operations for the VFD and LCD, and of course, it makes no sense to set up a character display on a device without one. As a result, we currently offer a module parameter to specify attached display type, solely so that people can actually use their 0xffdc devices. Now, if I actually had one of these devices myself, with some spare time to snoop usb traffic under Windows, I might be able to figure out what the Windows drivers are looking at to determine which device type they’re talking to…
Fortunately, SoundGraph got a clue for their current lineup of stuff, and we’ve got things as they should be, with unique device IDs per device type, no overlapping. For these devices, we can auto-configure all driver parameters automatically, since we know based on device ID alone exactly what sort of device it is (well, except for the devices we don’t know details on yet, because either they’ve not yet been made/shipped, or nobody that has one cares about Linux…). The imon driver’s device ID table for the current stuff looks like so:
/*
* Newer devices, all driven by the latest iMON Windows driver, full
* list of device IDs extracted via 'strings Setup/data1.hdr |grep 15c2'
* Need user input to fill in details on unknown devices.
*/
/* SoundGraph iMON OEM Touch LCD (IR & 7" VGA LCD) */
{ USB_DEVICE(0x15c2, 0x0034) },
/* SoundGraph iMON OEM Touch LCD (IR & 4.3" VGA LCD) */
{ USB_DEVICE(0x15c2, 0x0035) },
/* SoundGraph iMON OEM VFD (IR & VFD) */
{ USB_DEVICE(0x15c2, 0x0036) },
/* device specifics unknown */
{ USB_DEVICE(0x15c2, 0x0037) },
/* SoundGraph iMON OEM LCD (IR & LCD) */
{ USB_DEVICE(0x15c2, 0x0038) },
/* SoundGraph iMON UltraBay (IR & LCD) */
{ USB_DEVICE(0x15c2, 0x0039) },
/* device specifics unknown */
{ USB_DEVICE(0x15c2, 0x003a) },
/* device specifics unknown */
{ USB_DEVICE(0x15c2, 0x003b) },
/* SoundGraph iMON OEM Inside (IR only) */
{ USB_DEVICE(0x15c2, 0x003c) },
/* device specifics unknown */
{ USB_DEVICE(0x15c2, 0x003d) },
/* device specifics unknown */
{ USB_DEVICE(0x15c2, 0x003e) },
/* device specifics unknown */
{ USB_DEVICE(0x15c2, 0x003f) },
/* device specifics unknown */
{ USB_DEVICE(0x15c2, 0x0040) },
/* SoundGraph iMON MINI (IR only) */
{ USB_DEVICE(0x15c2, 0x0041) },
/* Antec Veris Multimedia Station EZ External (IR only) */
{ USB_DEVICE(0x15c2, 0x0042) },
/* Antec Veris Multimedia Station Basic Internal (IR only) */
{ USB_DEVICE(0x15c2, 0x0043) },
/* Antec Veris Multimedia Station Elite (IR & VFD) */
{ USB_DEVICE(0x15c2, 0x0044) },
/* Antec Veris Multimedia Station Premiere (IR & LCD) */
{ USB_DEVICE(0x15c2, 0x0045) },
/* device specifics unknown */
{ USB_DEVICE(0x15c2, 0x0046) },
I’ve personally got the Antec Veris Multimedia Station Elite (VFD, device ID 0×0044) and Premiere (LCD, device ID 0×0045) devices. Both work out of the box with the latest Fedora development kernels, and their displays, when coupled with lcdproc 0.5.3 (or later). No lirc involved at all (though I could use it if I wanted to, talking to the imon driver via lircd’s userspace devinput driver). The only thing that really required any config work was lcdproc — LCDd needs to be told which of its drivers to use, which is ‘imon’ for the iMON VFD devices, and ‘imonlcd’ for the iMON LCD devices, with Protocol=0 for an 0xffdc LCD and Protocol=1 for the newer/saner LCD.
Jan 17 2010
IR send/receive and the Hauppauge HD-PVR
The Hauppauge HD PVR has been a supported video capture device under Linux for quite some time now. The MythTV 0.22 release officially added support for it as a capture device under Linux. However, because the HD PVR records via an analog input, not via a tuner, you need a way to change channels on the device feeding it. The HD PVR has a built-in IR receiver and transmitter, sitting on an i2c bus on the device, not unlike a number of other Hauppauge devices. Well, with a wee bit of hacking on the hdpvr driver and the lirc_zilog driver, we *can* enable the IR part and use lirc with it.
Here’s a patch against the hdpvr v4l/dvb driver to enable the IR part:
* http://wilsonet.com/jarod/junk/hdpvr-ir/hdpvr-ir-enable.patch
Then you need lirc_zilog, which isn’t in the upstream lirc tree due to concerns over its use of a ‘firmware’ image for its IR transmit tables. I’m maintaining lirc_zilog in my lirc kernel driver git tree though:
Note that lirc_zilog started out as a rename of the old lirc_pvr150 driver, which started out as a fork of lirc_i2c, maintained by Mark Weaver, with details on it in his blog. lirc_zilog has been updated for use with newer kernels and more devices though, while the original is only targeted at the PVR-150 and no longer builds on current kernels. Another thing to note is that kernel 2.6.31 introduced a ton of i2c changes, so the lirc_zilog from my git tree won’t work with kernels prior to 2.6.31 anymore, unless you back out the i2c changes.
Once you have the driver built, there are still a few more steps to get things working. Oh yeah. Note that if you’re running Fedora 12 and its latest kernel, you don’t need to worry about any of the above, I already patched all the necessary bits into the Fedora kernel.
Either way, you still need a firmware image, a config file and some scripts to figure out which config stanza you need. Mark’s page includes links to the ‘firmware‘, which is really just a signal lookup table, extracted from the Windows driver. This file needs to go into /lib/firmware/ or wherever it is your distro puts kernel driver firmware images (any sane distro, it should be /lib/firmware these days). At this point, you should be able to load the lirc_zilog driver successfully and without any oopses (I still need to make it so the driver doesn’t oops if the firmware image isn’t found…). To be perfectly clear: the transmitter cannot transmit arbitrary IR commands, only those for which there’s a mapping in this pseudo-firmware table. If your device isn’t in the table, its probably not going to work. At least, not without a newer lookup table. A recommended step to take if you can’t get it working is to try under Windows with the latest Windows driver, which may have a newer table. If that works, we’ll probably want to get that table extracted from the Windows driver and make it available for the Linux driver to use.
Again, we’ll defer to Mark’s page, which includes a link to an lircd config file for the IR blaster to get you started. This file contains config stanzas for every device supported in the binary-only lookup table (aka ‘firmware’) you’ve loaded into the driver. Download it, drop it into /etc/lirc/lircd.conf, and start up lircd. Now you need to figure out which config stanza is the correct one for the device you need to transmit IR commands to. At this point, you should also be able to run irw, and see key presses registered from the flimsy little grey remote included with the HD PVR. Anyhow, back to figuring out the correct device… For me, the simplest thing to do was simply look at the table Mark put together and pick out the closest match to my device — which is cable box codeset 85 for the Motorola DCT6200 (I actually have a QIP6200, but same difference). If its not obvious at a glance which codeset you need, grab Mark’s script to cycle through sending the power button code for each possible config until it happens upon the right one. Once you’ve found the right one, you can edit /etc/lirc/lircd.conf, and strip out all the codesets that *aren’t* the right one. The last step is to then wire up a channel-change script in MythTV for your HD PVR capture device to use. Once again, we turn to Mark, and his channel changer, which you’ll simply need to edit to make sure its using the right codeset.
If during the above, or any time after, you’re having trouble getting any IR transmissions to register, there are a few things to note. First up, the transmitter should light up with each irsend command. If yours isn’t lighting up, its not properly connected, broken, or the driver isn’t actually working. Second, the transmit range is REALLY short, the transmitter needs to be positioned quite precisely over the reception target, or its not going to work — even a few centimeters to the left or right of the reception target, and its probably not going to work.
Now for the big caveat emptor: I believe at this stage, very few (if any) people have been able to actually use the IR part on their HD PVR under Linux reliably. At some point or another, while in the middle of video capture, the device completely deadlocks, and has to be reinitialized. Looking into the root cause of this is on my TODO list, but its a long list…
Jan 17 2010
lirc fail in Fedora
Ugh. Seems lirc_i2c doesn’t like to work when running the latest Fedora 11 kernel. I fixed the problem in 12, but never got the fix into 11, apparently. And in the latest pushed update kernel for Fedora 12, lirc_serial blows up (while it works in 11). Prime example of why we need to finally get lirc upstreamed, dammit… Anyway, the latest Fedora 11 and 12 2.6.32.x kernel builds have *both* fixed, so if you need either/both, try updating to that — they may be in updates-testing, or you may have to grab them straight out of the Fedora build system, not sure right now…
Next Page »