DAP Probes

In late November, I wrote about Universal DAP Support, where I posted a simple Mono tool that collected data about a Digital Audio Player, which could be used to help create FDI files for HAL.

I received many probes for various devices, including many duplicates. I have not yet found time to start implementing generic USB Mass Storage DAP support in Banshee, but doing so should be fairly simple and straight forward. Implementing a single class should be all that is necessary: Banshee.Dap.DapDevice. If anyone is interested in implementing this, please get in touch with me. If no one steps up to do this, it may be many more months before I can get around to it.

In somewhat of a response to James’ post, Rhythmbox Needs You!, I took about an hour this morning to filter through the probes in my mailbox and have published them. Many thanks to everyone who sent a probe! There’s no sense in them sitting stale in my mailbox for a few more months. And congratulations to Rhythmbox on Generic DAP support!

6 Replies to “DAP Probes”

  1. Read-only support for generic DAPs is fairly easy, whenever you detect[0] one, get it’s activation URI and recursively look for readable files under it. Write/sync support (which RB doesn’t have yet) is obviously more complicated, because you have to know whether there is a database you don’t know about or whatever.

    Do you want to to file bugs against Banshee, with summaries of how to read playlists off various players?

    [0] as well as using HAL’s “portable_audio_player” capability, RB will treat as a generic audio player any volume which has “.is_audio_player” in it’s top level. While originally for testing/debugging, it get left in because it was useful to people who had players HAL didn’t recognise yet.

  2. I submittted a patch to HAL for the Samsung YP-U1, which was accepted and checked in about a month ago. Hopefully that will save you a small amount of your time.

  3. James, I think that algorithm is too simple. My W800 phone has some MP3s that are ringtones etc, and others that are actually music and makes sense to sync.

    And many players don’t need a DB, iPod is a bit odd in that regard. Seems a shame to hold up support just because of that.

  4. James: the point of the data I was collection was to determine which devices actually have databases. We’re aiming to support those without databases first, at least for read/write. The data hopefully can tell us the file system layout: i.e. where music should go, what directory structure it’s in. Then it’s just a matter of recursively scanning this structure.

    I’ve been using portable_audio_player, but adding support for is_audio_player is a good idea. Thanks for your advise!

    Also, Gabriel Burt checked in a first pass at read-only support last night. Andrew: the more DAP FDI entries pushed upstream the better :) Gabriel is also working on turning these DAP probes into more FDI entries to go upstream.

    Mike: any serious player does need a database, if for nothing else than in the name of speed. Having to recursively scan a file system and parse metadata from those files, which means reading them over USB, is very slow. If you have a DAP with 5000 songs on it, I sure hope you have a database. A database benefits the player itself for the same reason. For smaller DAPs like the Muvos, a database is not as necessary. It’ll be interesting to see what we run into.

  5. It would be nice if ipod could be treated as a mass storage device (an option or something) because I’m running Rockbox and I don’t do iTunes playlists.

Comments are closed.