We must have universal DAP support!

Over the last few months there have been many requests for Banshee to support Digital Audio Players (DAPs) other than the iPod. Support for the iPod was initially most important: like it or not, the iPod has somewhere close to 50% of the entire marketshare for DAPs. The next most popular device line is the Creative Nomad/Zen Micro/Dell DJ family of DAPs (NJB). I have nearly completed my C# bindings to libnjb (njb-sharp from Mono SVN), which means NJB devices will be second to be support in Banshee.

However, I have been working on a very generalized “framework” for DAPs within Banshee. This week, I plan on refactoring the iPod support to implement this new model, implementing NJB, and implementing a base class for generic USB mass storage players (the kind where you just “drop” a file onto it, and it plays… no crazy databases or protocols necessary). This will make adding support for any DAP very simple. Each DAP implementations will be runtime-loadable, and none will be required to build the base Banshee.

Beneath it all is a HAL layer that fires off events to the proper DAP class instantiations when a new device with the portable_audio_player capability is connected.

Unfortunately, there is a slight problem. Very few FDI entries have been made for DAPs. In order for all the generic USB mass storage devices, and the Creative Nomads, Zen Micros, and Dell DJs, etc. to even be recognized as a DAP, the fdi/information/10freedesktop/10-usb-music-players.fdi FDI file needs your help. If you would like your DAP to be recognized as a portable audio player and it is not currently, I have written a small utility that collects information about your DAP from HAL. Simply ensure the device is disconnected, run make, connect the device, and wait 20 seconds. Mail me the result of the probe, and I’ll update the FDI file, and have it pushed upstream. The utility is written in C#, so you will need Mono. I left a precompiled assembly in src/, but if for some reason it refuses to run, try rebuilding it.

The utility can be found here: hal-device-capture-0.2.

I hope to have the generalized DAP framework in place this week for the 0.9.13 Thansgiving release of Banshee. If you are interested in actually adding support for your DAP of choice, please contact me!

Update: After reports of problems running the utility, I forgot I have Gtk# 2.7.1 installed locally, which means that’s what the utility was linked against. I have rebuilt it against Gtk# 1.0.

19 Replies to “We must have universal DAP support!”

  1. I tried compiling it, but though I have the gtk-cil package installed it returned this to me:

    ** (src/hal-device-capture.exe:7770): WARNING **: The following assembly referenced from /home/zbrox/compile/hal-device-capture-0.1/src/hal-device-capture.exe could not be loaded:
    Assembly: gtk-sharp (assemblyref_index=2)
    Public Key: 35e10195dab3c99f
    The assembly was not found in the Global Assembly Cache, a path listed in the MONO_PATH environment variable, or in the location of the executing assembly (/home/zbrox/compile/hal-device-capture-0.1/src/).

    ** (src/hal-device-capture.exe:7770): WARNING **: Missing method Init in assembly /home/zbrox/compile/hal-device-capture-0.1/src/hal-device-capture.exe, type Gtk.Application

    Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object

    Am I missing something? It would be great if you could help me.
    Thanks in advance!

  2. The precompiled version seems to require an unreleased version of gtk-sharp, but once I ran make clean in the src directory, it built fine against gtk-sharp 2.4.0 and detected by iAUDIO M3 correctly.

  3. Shame this framework is written in c# and not in C or C++ (with a c# wrapper). This means it won’t be of much use to any of the players that aren’t written in c#.

  4. Should the concept be extended even furthur (in tha case of USB mass storage DAPs) so that any device can be considered a DAP. For example my Dell PocketPC plays MP3s off its SD cards which I load with MP3s using a SD card reader. Will I have to run this program to register my USB reader and SD card as a MP3 device??

    It would be cool if any volume (network share, USB Mass Storage), CDRW, etc etc) could be treated equally without needing pre-knowledge of it by running this program.

  5. In the case of a multiuse device, where generic DAP capability exists, but files must be placed into a specific directory, is that path information something that should be expressed in the fdi? I’ve tried reading the HAL spec, but it seems out-of-step with the fdi files (portable_audio_player.type seems undefined, for example).

  6. I forgot I have a development version of Gtk# installed (2.7.1), so that may have caused problems running the utility against, say, Gtk# 2.4. I updated the post with a link to a new tarball with the utility built against Gtk# 1.0.

    So for the case of generic multi-purpose DAPs, ideally it would be nice to specify a path relative to the root of the device into which audio files must be placed as a property on the device in HAL. I will take a look at the HAL specs, but this may need to be done by subclassing the generic USB mass storage device class in the Banshee.Dap namespace.

    Now for the case of DAPs that support removable media like SD cards, there isn’t really a way to expose them as “DAPs” per-say, nor does that make much sense. However, you can export music to Nautilus by drag and drop. I’m open to ideas regarding this case.

    Also, this program does not make your device a DAP. It just collects information about the device from HAL so that we can expand on the DAP FDI file so that in future releases of HAL, it will be detected as a DAP.

  7. Isn’t it better to always include support for all players? It’s all about the “plug-n-play” experience, isn’t it? The support code can’t be that big..

  8. The olympus m:robe series use the mpv storage method. I tried decifiering thier documentation, however no luck.

  9. Recompiling didn’t help either, trying to point it to libdbus-1-2 that I should have installed didn’t help at all either… running Ubuntu-dapper.

  10. Nice flooding, and thanks so much for pasting my email address! I’m editing your first comment to trim it down and keep that address from getting harvested.

    I’m guessing that Dapper now has DBus 0.6 or better, which means the so version changed to .2. You can try changing “libdbus-1.so.1” to “libdbus-1.so.2” in the target attribute of the first dllmap element. Try different variations too, I don’t know what it may be exactly.

  11. Okay, I must be a spaz.

    But how do I send you the details for the device?

    I couldn’t find the application you wrote, however used hal-device, and copied the data relevant to the dap, hopefully that is enough information that you need.

    Now if only I can find some way to send it to you ;)

    Any thoughts?

Comments are closed.