Monthly Archives: August 2005

entagged-sharp in Beagle

I’ve recently been hacking on entagged-sharp, a C# library for extracting tags from audio files. This is used in Banshee, Muine, and probably some other projects too.

It provides a nice simplistic interface for extracting tags, e.g.:

AudioFileWrapper afw = new AudioFileWrapper("/path/to/audio.file");
Console.WriteLine("{0} - {1}", afw.Artist, afw.Title);

…and this will “just work” for all of the audio file formats that are supported.

I worked on extending the AudioFileWrapper interface, reducing internal abstraction, MIME support, unit tests, bug fixing, and adding Amiga module audio file support. ASF/WMA tag filtering is coming soon.

entagged-sharp has now been imported into Beagle CVS, replacing the filtering code we had previously. This pretty much closed all the audio-filtering bugs that we had, and added support for more formats (m4a, m4p, xm, sm, it, mod). Hopefully nothing broke at the same time :)

Linux 2.6.13

2.6.13 is here and will soon be in Portage (as testing) for Gentoo users. One thing that will almost certainly cause disruption is that devfs has finally been removed from the kernel, so you pretty much must use udev. If you don’t have udev installed, it will be installed as a dependency of the 2.6.13 kernels, so hopefully the problems should be minimized and udev will just work when you reboot.

Some more of the notable changes I’ve been following since 2.6.12:

  • inotify is now included, which is a mechanism where the kernel tells user-space when a file or directory changes. Very useful for those situations where applications need to watch for a file or directory change, which is common.
  • kexec – optional fast reboots which don’t need to fully reboot and go through all the BIOS initialization again, another kernel is booted directly from the old one.
  • skge is now included, a driver for SysKonnect Yukon network adapters which actually works (a driver for Yukon-II adapters, sky2, will hopefully be included in 2.6.14)
  • it8212 is finally included, a driver for a popular IDE RAID adapter found on many motherboards
  • HZ (frequency of timer interrupt) now defaults to 250 (ticks per second) and is configurable, which might increase battery life on laptops, but this change is still under debate
  • Lots of bug fixes, new hardware support, more drivers, and other stuff which I have missed

AFFS Annual Conference

Gentoo UK were invited to attend the AFFS Annual Conference at short notice. Myself, George (cokehabit), Rob (tigger), Stuart, and Tim (plasmaroo) attended, and Tim did a nice talk titled ‘Introduction to Gentoo’. There were also talks on software patents, Hula, and Debian.

There weren’t many people there – the event didn’t seem very well publicized, yet we met a few happy users and met with AFFS for the first time. Look out for more info in the next Gentoo newsletter.

Fuji DPC-R1 is an Alauda!

I have been making some fast progress with the Alauda driver project.

I discovered that the Fuji DPC-R1 is also an Alauda device, so my driver should result in this device being supported by Linux, as well as the Olympus MAUSB-10 which I have in my posession.

I’ve gone over several logs of sniffed data and documented what I think it’s doing on the new sourceforge project page: control commands and bulk commands.

The first thing I want to achieve is the reading of my XD media cards. The Alauda only provides raw access to the media, so I basically have to interpret XD in software. This is made difficult because XD is closed-spec and it doesn’t look like anybody has done it in software before (well, not open-source!), but fortunately it is similar to SmartMedia (the SDDR09 Linux driver handles “raw SM” in software, and this is proving useful to look at). I’ve published what I think might be something vaguely like the XD Media specification.

Once I’ve figured out a few more details about XD media, I should be able to get reading working relatively easily. I’ve got the driver foundations in place already.

I’m hoping that I’ll hear from some other MAUSB-10/DPC-R1 users soon to get additional testing when I actually have some code which does something useful.

Reverse Engineering

I recieved two emails in response to my last post, both from people owning slightly obscure hardware wondering how they might be able to reverse engineer it and possibly get Linux driver production underway.

The first step is to spy on the device during normal usage. In the case of the Alauda, this means monitoring all USB port traffic while using the device under Windows using the vendor-supplied driver.

Fortunately this is relatively easy to do with USB, you can use software such as USBSnoop on windows which will log all the traffic to a file. Other hardware is not so easy, sometimes you have to resort to expensive “middle-man” hardware devices which monitor and record the traffic for you.

After logging a few sessions, you then have the daunting task of analysing the logs. They are cryptic and hard to understand at first. Here is a small part of a USBSnoop log right after plugging in the MAUSB-10:

[93 ms]  >>>  URB 6 going down  >>> 
  TransferFlags          = 00000001 (USBD_TRANSFER_DIRECTION_IN, ~USBD_SHORT_TRANSFER_OK)
  TransferBufferLength = 00000002
  TransferBuffer       = f6a77d3c
  TransferBufferMDL    = 00000000
  UrbLink                 = 00000000
  RequestTypeReservedBits = 00000000
  Request                 = 00000008
  Value                   = 00000000
  Index                   = 00000001
[94 ms]  < <<  URB 6 coming back  <<< 
  PipeHandle           = 81b72c20
  TransferBufferLength = 00000002
  TransferBuffer       = f6a77d3c
  TransferBufferMDL    = 81c029e0
    00000000: 80 01
  UrbLink              = 00000000
  SetupPacket          =
    00000000: c0 08 00 00 01 00 02 00

This starts to make more sense after reading the USB specs – the host computer is sending a command to the device and gets 2 bytes of data back (0x80 0x01) in return. I think that this particular command is querying the device status, and 80 01 means not ready yet. After 10 or so of these commands have been sent, the final one returns a new value of “0x14 0x01”, and after that, all kinds of crazy stuff starts happening, so 14 01 somehow indicates that the device is ready for action.

Once you have an idea about which command does what, and how to interpret the responses, you can then start writing code to mimick what the windows driver does. I’ve archived a good HOWTO (slightly out of date) which provides an introduction to this: Reverse engineering Windows USB device drivers for the purpose of creating compatible device drivers for Linux.

Obviously the process will be different for non-USB devices, but I hope this shows that while it’s an interesting experience, reverse engineering is pretty damn hard, especially you have so little to go on. It’s much easier if you can get a copy of the manufacturers technical documents, which is sometimes possible.

Alauda MAUSB-10

Got my hands on an Olympus MAUSB-10:

It’s a USB media card reader (2 slots, SmartMedia and XD-Media). It uses a vendor-specific interface and protocol, and is currently unsupported by Linux.

I’m going to be slowly developing a driver for this device. The Windows driver shows that the driver is actually for an “Alauda Enumerator” chip, maybe manufactured by RATOC? I’m going to be a copycat and call my driver Alauda.

I’ve fired off an email to Olympus requesting technical documentation for the device, but I’m doubtful that I’ll get anything – I’ll probably have to reverse engineer it from scratch.

Some techy info, the device seems to use a combined Control/Bulk transport, where bulk is used for data transfer and control is used for everything else (get media status, etc). Commands seem to be transmitted via bulk (after control setup) and hopefully they are something standardised e.g. SCSI/ATA, but I haven’t had time to investigate this just yet.

If anyone else owns one of these and would be interested in development/testing, please email me.

I will upload sniffed logs from the Windows driver and an initial protocol analysis sometime soon.