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

[David Zeuthen <david fubar dk>]

On Mon, Jun 21, 2004 at 10:19:18AM +0100, Bastien Nocera wrote:
> The iPod is quite different from those players in that it requires a
> database to be updated at the same time, and a particular hierarchy.
> 
> So, you will need special support for that device anyway.
> 

HAL is not panacea, it'll only tell you what the device is not how
to use it, so in every case you need to write specialised code for
specialised devices like e.g. the iPid

The portable_audio_player.type I've was talking about below should
solve this; so, yeah simple flash-based player without need for
database updates would be "type 1", iPod may be "type 2", future
players "type 3" and so on.

Maybe making the .type a string with "no_db_updates",
"ipod_db_updates" etc. would be better?

The thing is, there's a lot of OEM's just using the same chipset - so
with some effort users can tinker with changing the .type and see if
it works. Then if it works, they can submit the .fdi file to a free
software hardware directory like the one proposed on the HAL mailing
list the other day. OS vendors could pull info from such a directory.

> > 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>
> 
> What's "input.formats_accepted" for? 

To specify what kind of files the device accept; I suppose some/most
people have their music in ogg format but have a mp3 player only. So
you would need to transcode the files when transferring them right?

> In all that, you also need the
> directory where the user would put the files, otherwise, you'll have to
> write special code again.
> 

Yeah, but that's just descending into the device tree as I say below:

> > 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. 
> 
> Actually, I'm looking for the "Block Device" (the /udev/sda, parent of
> the partitions). Then looking for the only mounted child.
> 

Right. Exactly. 

So you would do hal_find_by_capability ("portable_music_player") and then
descent from there until you reach a HalDevice with capability 'volume'.
You may need to mount it yourself, but g-v-m may have done so already!
Either way, when it's mounted you get the mount point and so on.

> > 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.
> 
> I don't think that there are anymore devices like the rio500 that
> require a special protocol on the market, not in those kind of sizes
> anyway (most of them just want a directory for you to dump the files
> in).
> 

Ok, that's good news.

> (See http://www.ic.unicamp.br/~oliva/snapshots/FC2-firewire/ for
> firewire on Fedora, basically, now, it works with 2.6.6)
> 

Thanks, I'm going to try that.

> > 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? :-)
> 
> All for that :)
> 

:-)

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

Right, I think there were some discussion on d-d-l on moving the capplet
into a more general configuration solution.

> >  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
> 
> Given.
> 
> >  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)
> 
> That sounds like a bad idea, IMO.
> 

Why? The transcoding we'll need for sure, right? I mean, most players only
support mp3 and we shouldn't force people to have their music collection
in mp3 just so it's easy to transfer to their mp3 player, no?

> > 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?
> 
> I think that there are bits missing to support the "low-end" MP3 players
> (the common flash based ones nowadays), but that there'll still be work
> needed for the bigger ones that requires a database before they operate
> properly. 

I hope my response clarifies that this proposal does support low-end
flash based players. 

I also think this belongs in the HAL spec, if you want I can take a
stab at putting it into that document? I want to update before GAUDEC
anyway :-)

> (BTW, you'll also want to detect those players that work on
> top of Ethernet ;)
> 

That would probably be best solved with some Zeroconf/Rendezvous
technology or something, I don't think HAL can help here :-)

> Cheers
> 
> > [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 :-)
> 
> Hehe. I don't think Totem will have a "library" to speak of any time
> soon. But just a simple "copy playlist files to portable video player"
> would be easy enough :)
> 

The sky is the limit :-)

Cheers,
David