Just to follow up the earlier post, I officially announce my Karma driver web page, including the kernel patch such as it is. I’ve worked out some more details about the disk so I expect to be able to mount it shortly. Peter from empeg declares it “could be useful.”
My poor MP3 player is destined to be relegated to the trash heap with all of the other Not-An-iPods. For good reason, really, since I have broken it in several different ways since I’ve had it: first the hard drive failed, then after replacing the unit, I dropped the new one and the scroll wheel broke off, and the battery leads came off the mainboard. I’ve soldered the battery back on and glued the scroll wheel back, so it continues to hobble along. Other than build quality, it is a fine MP3 player: it does OGG and FLAC, gapless, has a decent UI, fits nicely in one’s pocket.
What is most annoying about this device is that you have to use Rio’s software to transfer stuff to it over USB, and this only works in Windows. Otherwise, you are stuck using a Java app over ethernet in Linux which is sloooooooow. It would be nice if you could just use it like any old hard drive. Imagine being able to use a hard drive like a hard drive!
So, armed with the recent purchase of the book Linux Device Drivers, I have set out to reverse engineer this bad boy. It isn’t a straight up mass storage device, but if you poke around on it you can make it enter mass storage mode (also, you can make it reboot). From there, it should be a “simple” matter of using dd and figuring out the file system to make this thing a bit more user-friendly.
It took me a couple weeks of looking at hex dumps, but I’ve got phase one completed. Life is good.
Aug 17 08:09:10 dust kernel: usb 1-2: new high speed USB device using address 2
Aug 17 08:09:10 dust kernel: usb 1-2: Product: Rio Karma
Aug 17 08:09:10 dust kernel: usb 1-2: Manufacturer: Rio
Aug 17 08:09:10 dust kernel: usb 1-2: SerialNumber: 00000000000000000
Aug 17 08:09:15 dust kernel: scsi0 : SCSI emulation for USB Mass Storage devices
Aug 17 08:09:15 dust kernel: Vendor: Rio Model: Rio Karma Rev: 0101
Aug 17 08:09:15 dust kernel: Type: Direct-Access ANSI SCSI revision: 02
Aug 17 08:09:15 dust kernel: SCSI device sda: 39070080 512-byte hdwr sectors (20004 MB)
Allow me to enumerate the many ways I hate JAXB. JAXB is an XML data binding tool for Java; that is, it generates code to make using XML more Java-like. This is great in concept. In reality it is not so great:
- Two days away from your project due date, JAXB lets you know that it isn’t mindful of the method size limits in the JVM. Javac tells you: “code too large.”
- There’s a limit to method sizes in the JVM?
- Upon examining a generated class, you discover 25k lines of utter garbage. Things like the same if-then clause being repeated twice in a row.
- Turning off generation of the validator, or the unmarshaller, or the validating unmarshaller does have the effect of reducing code size, at a cost of generating code that doesn’t compile.
- Or if it compiles, it throws a runtime exception when you use it.
- The object hierarchy is all screwed up, such that a concrete implementation type may implement a (JAXB internal) interface that is not also implemented by the corresponding abstract interface (the two are supposed to be interchangeable).
- You have to do naughty proprietary things to make type substitution work.
- Creates a new namespace prefix for practically every element even though I only use 3 namespaces in the entire document.
I only just learned about XMLBeans. Dammit.
Hmmm, think my app is network I/O bound? EJBs are great!
$ time ./run.sh
My jukebox program is now official.
What do you do when you have 300 CDs ripped and encoded on your living room PC, an affinity for perl, and two hours of commute time on the bus every day? What else — you make a remote-controlled kiosk style jukebox. Here’s a peek at the TV interface: