jefferai

Introducing Alejandro Wainzinger (xevix on IRC), who is going to be working on media device support in Amarok for SoC 2008:


My name is Alejandro Wainzinger, and I'm going for a Computer Science B.S. at the University of California Santa Cruz, USA. This summer, I'll be bringing back media device support to Amarok for Apple iPods, MTP and generic devices, and making them fly. I chose this project because I own an iPod, and got frustrated with the speed of loading an iPod with a large database, sync'ing of songs/playlists and album art, unlogged crashes after trying to put a 10,000 song queue onto the iPod, and slightly unreliable iPod model detection. That said, I loved having iPod capability in Amarok, and I couldn't see Amarok 2 without media device support.


Alejandro is going to work on getting normal functionality for all three types of devices, and then really taking the iPod plugin to town.

Rumor has it he's then going to attempt making collections out of the devices...

Update: Since I've gotten a few relatively profane comments (which I've elected not to post) about blah blah pissing contest blah blah cant we all work together blah blah you are a stupid moron blah blah, please note that nowhere in this post did I mention Qt. This was not a "my widget set is better than your widget set" post. This was a "WTF, why can't I resize this box properly, and why does it end up moving up into the toolbar, how silly of it" post. If it's broken, it's broken, and since I found this to be broken in an amusing way, I thought I'd share it with others. Everyone likes to laugh, after all. So essentially: chill out.

I've been rather silent on the topic of progress in media devices. Part of this is that much of the work has happened behind the scenes. Just yesterday I spent hours editing device definitions in libmtp and libnjb so that they'd be able to propagate the correct vendor and product info through hal, because hal's handling of it leaves something to be desired. For instance, on my Creative Zen MicroPhoto, it correctly detected the vendor and product. Except that the part of the device detected as a portable media player was the USB interface for the device, for which the vendor was blank and the product name was "USB Interface."

Another reason for the long delay was a partially failed experiment that aimed to provide support for many different media devices via a centralized kioslave. It's not that this couldn't still happen, at some point, but it becomes extremely difficult to map protocols that have no notion of filesystems into a filesystem, and have filesystem clients behave properly. There was another foray into a different system that also ended badly -- mainly because there was no way I'd get it finished within a year, much less within a few months.

In the end it was decided that Amarok's device plugin system is really pretty decent, providing relatively bug-free and easy device management for almost every device on the market...and if it ain't broke, don't fix it. Of course, it's using tons of deprecated classes and methods, but as Trolltech says (my emphasis), "we recommend against using these classes in new code." Good point. So let's get stuff working, and then we can try to design a new, better system in parallel -- but at least something will work in the meantime.

So with that decision made, I worked on integrating with Solid. I'm happy to report that today, I plugged in my Creative Zen MicroPhoto, and it was instantly detected and the correct plugin selected. All I had to do was hit Connect. Screenshots:

The first screenshot shows what the media browser looks like with nothing plugged in. At that point, I plugged in my Creative Zen MicroPhoto, and you can see that it was detected and added to the device selector drop-down box:

After this, I hit the Connect button (it's the one on the top left) and artists were displayed. I hit the custom button just so you could see some of the details available:

So it's coming along. I expect this device detection to work on pretty much any kind of music player (except generic/vfat/UMS...more on that on a later post, when I have time to work on it), provided that:

1. hal is installed and working.
2. You are using a recent version of libmtp/libnjb for those devices. I've also worked with libkarma and libifp but have been unable to actually check them out to see how they're working since I don't have those devices. We're probably going to start a "send us your old media devices" thing going, so that I can work on all of them. libgpod was more hesitant about working with me, but there's a problem there anyways, as apparently you can't detect from the USB interface the iPod exposes what kind of iPod it actually is, without connecting to it. Feel free to blame Apple on this one, as it's probably on purpose in an attempt to keep you on iTunes. So there's a generic definition already in hal which should be (hopefully, pending testing, send me your old iPods) good enough to at least have it show up as an iPod. Once you click the connect button the library should be able to provide more info.
3. Your distribution's package of the device access libraries installs the hal fdi files provided by the libraries. For some unfathomable reason many (most?) don't -- even my beloved Gentoo. So start bugging your package maintainers early, because if you don't have these installed, you're not going to get autodetecting goodness. Some of these may end up in the main HAL distribution (I have repo access so can add them in) but for many it doesn't make sense as they're constantly being updated or changed, and it would require changing in two places instead of one. (Also, some libraries generate these automatically, instead of having a fixed file).

So that's it for now. The next step is to get manual adding of devices working again. And after that, dealing with generic devices in a smart way (the way will be Banshee-compatible too...thanks to Aaron Bockover for the excellent idea!) In the meantime, watch out for the Amarok Device Donation Program.

There's been a lot of hubbub lately about Safari being released on Windows, which is based on WebKit, which is based on KHTML, and how it'll beat Konqueror as the first KHTML-based browser on Windows.

Then you hear this other camp firing back about Swift, whose homepage proudly declares "The First KHTML Browser for Windows."

However, I'm here to set the record straight. To the best of my knowledge the first KHTML-based browser on Windows is ThunderHawk, which appears to have been using KHTML under-the-hood since at least 2004 and probably at least 2002.

Yes, it's a WinCE/Windows Mobile browser. But it's still Windows.

My blog's been rather inactive for a while. Most of this has been because of being busy, and because of not doing hugely exciting things when I have had Amarok hacking time (mainly some bugfixes in stable branch). But now something's come along that warrants an entry.

Amarok's device handling is pretty adequate. Granted it could be better, but we support nearly every device on the market through some plugin or another. But there's one recurring problem: except in a few cases, Amarok doesn't know what device you have plugged in, and how to handle it. You have to tell this to Amarok. This means you, and we, have to deal with the manual creation of devices. Well, that's going to change.

Enter HAL, and its KDE4 paramour Solid. By now, you probably know what these do. HAL, Hardware Abstraction Layer, gathers information about your hardware. Solid reads it (and some other information) and outputs a KDE interface to it. Now by itself, this isn't enough, because HAL has a namespace called portable_audio_player, but, with a few exceptions, it doesn't actually say what type of device you're using -- simply "storage" for a USB Mass Storage interface, or "user" meaning that a userspace library needs to handle it.

However, for the last few weeks I've been working with HAL developers and the developers of libgpod, libifp, libkarma, libnjb, and libmtp. The goal has been to come up with a way that device access protocols can be auto-detected. If you know what access protocol a device uses, you can load the appropriate plugin automatically. Well, this has been done, and as a result the HAL portable_audio_player namespace spec is being modified to allow libraries to insert information they know about devices into HAL -- while at the same time keeping libraries from clobbering each other. Interested parties can find a draft version here, with the final verison going into HAL as soon as the slugs at freedesktop.org set up my account.

After this, I will be adding proper entries in libmtp and libnjb (easy, since I have commit access for both), making entries for libifp and libgpod, and working with the libkarma developers for their entries. After all this is done (probably in the next couple weeks), Amarok 2.0 and other HAL-aware clients should be able to determine and load the correct plugin for just about any device on the market, automatically. Okay...after a lot more hacking on 2.0...but you get the picture.

I'm hoping that when this is done we can remove manual device addition/deletion. It's a complex part of the code that can be difficult to maintain, and shouldn't be necessary any longer -- if you have a library that can handle the device that Amarok can use, Amarok should already know about the device from HAL. Even generic USB Mass Storage players should be fine, because they should be detected by HAL and exported through Solid as storage volumes. The only thing I can see this affecting negatively is the generic device plugin that just got fixed to support arbitrary KIO paths but I've been thinking about pulling that into the Collection some way anyways, now that the Collection can handle many sources, as this would let it handle lots of sources

I've been knocking down my to-do list like there's no tomorrow. I posted recently about the VFAT device rewrite; it is now complete and early testing results seem to be positive (it's been renamed to "Generic Audio Player" by the way). In addition, ATF backend support should now be fairly complete. I've been debugging it for a while and everything seems to work well now. It catches file copies, moves, and renames, and lets you assign new IDs to files through a DCOP call. It doesn't slow down scanning much either (I've been scanning 2082 files in about 30 seconds or so). I have yet to test it on Oggs, but I would imagine that it'd be fairly simple to get that working too.

The next hurdle is actually making amaroK components use ATF. I don't think that will happen in time for 1.4 final, but in the point releases thereafter hopefully you'll start to see some components take advantage of the features that ATF provides, to help it really live up to its name.

The VFAT rewrite continues apace (it may get renamed for 1.4 final).  Many functions have now been implemented, and far from scaring me, I now feel quite comfortable with the code I've written.  Just goes to show how taking a fresh perspective can really make a difference.  It should be working much better than the previous incarnation of the plugin once it's done, and hopefully folks using 1.4 final will be happy with it.

While updating my box at work today to kernel 2.6.16, I noticed that it now has support for Rio Karma partitions.  This rocks, as the Karma is a very capable player that can play FLAC (and I think Ogg Vorbis) in addition to MP3, but previous had no Linux support.  I'll have to find a time to grab my girlfriend's Karma and give it a go...if she lets me...

    ATF stuff has taken a backseat for a bit while I rewrite the VFAT device plugin. Originally I had ported the code over from the ifp media device plugin...the problem is that to deal with the differences between the two kinds of devices the code quickly became full of hacks. Changing one thing meant five other things broke...a bad situation. I've known for a while I would need to redo it, but I was procrastinating because I hated working on it so much, but now that we have a planned release date for 1.4 final, well, I figured it was time to get it over with.

    The good news is that this time, I'm not hating it as much. This is mainly because I've started with a much more hierarchial design that makes tasks that were complex and error-prone in the old device code much more simple and reliable. The end result should be a device plugin that is much more stable and doesn't have as many weird quirks -- with any continuing quirks fixed quickly, of course!

    Today I got done with enough code to display the filesystem and allow for expanding directories. This may not sound like much, but it's actually a good sign, as these functions seem to work well and stably, and these basic functions being completed means that all the under-the-hood code is working (which was the majority of the rewrite), so the rest of the functions will be easy to implement. And the best news of all is that unlike the old code, I'm very confident in this new code!

    Yesterday I commited some code to the Collection Browser that allows it to accept URLs with the audiocd:/ protocol.  If your machine supports this (the audiocd:/ kioslave is probably in the kdemultimedia package), you can rip by doing the following;

1. Open KControl.  Go to Sound and Multimedia->Audio CDs.  Configure your ripping preferences.
2. Open Konqueror. Go to audiocd:/
3. Go into whatever folder you want your tracks encoded as, i.e. Ogg Vorbis will contain Vorbis "files" that you can select.
4. Drag these tracks to amaroK's Collection Browser.

amaroK will perform a KIO copy, which will result in a seamless rip of the track and import of the track into your collection.  Easy as pie, and using KDE's built-in capabilities to boot!

ATF, or Advanced Tag Features, will hopefully enable a whole range of really cool features in amaroK. I've updated the Wiki with new information that reflects the changes that have gone on. Fortunately none have been in the API, just under-the-hood changes. Regardless, as it's still so new and untested, I doubt anyone's turned it on except for me anyways. Heh.