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.
> http://www.hadess.net/files/shots/21-06-2004.1.jpg
> 
> 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

 http://www.jetflashusa.com/shop_detail.asp?product_id=16

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">
   <device>
     <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>

         </match>
       </match>
     </match>
   </device>
 </deviceinfo>

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?

Cheers,
David

[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]