Re: [Rhythmbox-devel] xine metadata, and iPod HAL support

On Mon, 2004-06-21 at 02:30 +0100, Bastien Nocera wrote:
> Heya,

Heya Bastien,

> Here's my free time's worth. First is a xine-lib metadata backend (which
> I sent some time ago). It's not finished quite yet, but it's disabled by
> default.
> The rest is HAL support for the iPod source, with a bit of refactoring
> for the existing code.
> Enjoy.

Very nice, I've been thinking a long time about looking into portable
player stuff for Rhythmbox using HAL. I don't have an iPod but I do
happen to own one of these flash based USB drivers with mp3 support,
namely this one

According to specs this device happen to support output of MP3 and WMA
and it has some voice recording function as well. I only tried the MP3
stuff though.

So, for a long term plan, which I'm proposing here :-), all I think is
necessary is to create a capability and namespace in HAL called
'portable_audio_device' [1] and the device information file for *my*
device could look like this (0x066f,0x8000 is the USB vendorId,
productId pair)

 <?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- --> 

 <deviceinfo version="0.2">
     <match key="info.bus" string="usb">
       <match key="usb.vendor_id" int="0x066f">
         <match key="usb.product_id" int="0x8000">
           <merge key="info.category" type="string">portable_audio_player</merge>
           <merge key="info.capabilities" type="string">portable_audio_player</merge>

           <!-- An abstract number telling how this device like the metadata to be updated  -->
           <merge key="portable_audio_player.type" type="int">0</int>

           <!-- list of audio formats this device can play (should be MIME types) -->
           <merge key="portable_audio_player.output.formats_accepted" type="string">mp3 wma</merge>

           <!-- list of audio formats this device can record (should be MIME types) -->
           <merge key="portable_audio_player.input.formats_accepted" type="string">wav</merge>


and you would have similar files for the iPod products, the Minidisc
players (once someone fixes the ATTRAC stuff) and other existing
products. For usb-storage and sbp2-based devices, e.g. storage devices,
you would simply have the device tree

 - USB device        <--- tagged as portable_audio_player
  - USB interface
   - SCSI host
    - SCSI device
     - Block device
      - Block device (partition)
      - Block device (partition)

and search down the chain; I guess this is what you're doing today for
your iPod? Btw, is it firewire? Can't get my firewire disk to work on
Fedora. Oh well. 

Continuing, for devices with a proprietary protocol (from top of my
head, isn't the Rio500 this way?) it looks like this

 - USB device        <--- tagged as portable_audio_player
  - USB interface

and you would use libusb or whatever is already implemented and get USB
addressing details from the usb.* properties on the HAL device. You'd
probably want a portable_music_player property telling how to access the
device or something.

Now, with this approach we could do a lot of cool things, here's some

 1. change the hal gnome-vfs patch slightly such that Nautilus shows a
    suitable cool icon for the device; yay, I guess we're all in for the
    eye candy, right? :-)

 2. get gnome-volume-manager to automatically launch Rhythmbox when
    a 'portable_music_player' device is detected

 3. share these details with KDE apps like JuK or amaroK since all the
    HAL stuff happens on the system-level rather than the distro-level

 4. automatically support newer players with weird formats without
    recompiling Rhythmbox (only e.g. update gstreamer) since I guess the
    re-encoding part can be automated (you want to reencode from .ogg
    to export to your mp3/wma only player)

The only work on the HAL details is basically the portable_audio_player
capability and namespace that I need to put in the HAL spec and of
course a bunch of .fdi files. The workload on the Rhythmbox side for
this proposal sounds a bit higher though. 

How does this proposal sound?


[1] : in search of a better and shorter name, but I want it to be
descriptive as one day you might have 'portable_video_player' as well
that another GNOME app might support, Totem maybe? And future devices
with both video and audio would support both :-)

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]