XMMS2

Summer of Code 2008 officially kicked off on May 26. Within two days, I had about 1500 lines of C written for the result/value split needed for service clients to have a clean API. I started out by writing a patch that was just enough to split ... [More] xmmsc_result_t into xmmsc_result_t and xmmsc_result_value_t. Then I got the suggestion to create common implementations of all the types used by XMMS2's IPC and encapsulate them in an xmmsc_value_t. That accounted for about 1400 of the 1500 lines of code. :)As it turned out, all that work wasn't necessary and only the original patch was needed. Fellow XMMS2ers theefer (Sébastien Cevey) and nesciens (Erik Massop) took over from where the patch left off, completely separating the two structures and even converting the CLI code to use the new value_t. So now, service clients will be able to pass arguments and return values around conveniently as xmmsc_value_ts.Now the big question in my mind is how do I merge this beast? Somehow, I need to get service client code on top of the result/value split code. Do I simply rebase the code and resolve every conflict I can see as I go? Do I squash the service client code down to a few commits? What about authorship in both cases? One thing is certain; it's going to be very hard to visualize everything that needs changing to use the new value_t. But I guess this is just another lesson in how developers do things in the real world and why small, incremental commits are so useful in preventing this situation.So I suppose there is really only one option: to rebase and pray that it's not impossible to fix. But that's the biggest obstacle in the way of getting service clients into the next release. Anything for the t-shirt! [Less]

It's that time again. People are walking around in flip-flops, getting tan(ner), and licking ice cream from cones. It's summer (or it's close enough, anyway), and this summer I'll be getting my tan from the computer monitor and my ice cream from the ... [More] freezer. It'll be a basement-dweller's summer for me as I'm coding on XMMS2 in this year's Google Summer of Code.I'll be working on service clients, a continuation of last year's unmerged work. The concept is to provide so-called "service" clients which perform a service (surprise!) that can be re-used by other clients so client authors aren't reinventing wheels all the time. It's just another way XMMS2 eases music player development to the point where making your own interface is a weekend project instead of a thesis project.What Service Clients AreThe client-server nature of XMMS2 is a constant issue when trying to add new features or fix bugs. What was trivial to accomplish in a monolithic music player is not so trivial in XMMS2, and vice-versa. Service clients are a way to provide the same whipped-cream-and-cherry features you'd find in a monolithic client, but in a reusable, modular, and extensible form. It's cleaner than adding new stuff straight to the daemon, but still fairly simple and straightforward to use.Service clients work by registering themselves and their callable methods with the XMMS2 daemon. Regular clients (or even service clients, as they're regular clients, too) request a service client from the daemon and call its methods appropriately and get back data. It's that simple. Album art lookup, tag lookup, last.fm submissions, and FreeDB lookup are all easily written as service clients and their functionality is very easily included in any client by use of a few methods. Services are even browseable so, with a little user intervention, a new service client could be used from a client that has no idea how to use the service, at least in theory.What This SoC Will BringService clients were part of last year's Summer of Code program, completed by student Ning "zeegeek" Shi under the direction of mentor Sébastien "theefer" Cevey. The API works and there are a couple service clients floating around, but zeegeek's codebase was never merged with the main XMMS2 tree. The code needs a full review and some questions about remaining oddities answered. A little bitrot has accumulated since last summer, too. My job will be to clean up the code and get it merged, first.Later I'll also be writing the first language bindings in Ruby. This, too will be followed by a merge. Too often, Summer of Code projects are completed but remain unmerged for months, creating lots of work later. This summer, I'm including merges as part of the project goals. Once the service client API and Ruby bindings are completed and merged, it's time to take service clients' virginity. It won't be just a framework anymore, but I'll implement some useful clients, starting with a port of xmms2-scrobbler. And of course, this'll be followed by a merge as well.Then more cool clients will follow. The next generation of collections, (Collections 2.0) also being implemented this summer, will probably implement the collections parser and a more flexible party shuffle as service clients. This is an exciting collaboration opportunity. Other possibilities include a medialib-updater styled service, taglib client, FreeDB/musicbrainz lookup, and album art lookup. I'm outlining way more service clients than I can handle this summer in the hopes that I can pick out an important and doable few and get those few done and merged by the end of SoC. They'll also be indispensable means of clearing up remaining kinks and bugs in the code while establishing some good example code and helping me write documentation.Working on service clients this summer is exciting and I'm overjoyed that this is my first SoC. This is an excellent project with an excellent team during an excellent summer, so I've little doubt that all this year's projects will be successful. I'm hyped, and you should be, too! Stay tuned for when I finally settle down with a six-pack and start exercising my fingers. [Less]

Buildbot is nice… I use it for the XMMS2 project, and I use it at work. However, the hellspawn OS known as Windows likes to tell the user if some executable crashes. This might be nice and user-friendly as it’s a pretty common scenario that ... [More] applications crash on this OS, but when running unittests in a buildbot slave this causes the slave to hang instead as there’s nobody watching the screen and clicking the ok button in the dialog box. Killing the application with the Win32-api doesn’t help as the message box heavily guarded by the OS (…or rather the result of another application intercepting the crash). I bet others have stumbled upon this disturbing issue, and like me don’t know that much about the OS in question, so here’s one solution that works: Disable problem reporting in “Properties in My Computer” Disable JIT debugging in “Tools->Options->Debug” in Visual Studio versions Enable drwatson by running drwtsn32.exe -i [Less]

Google was kind enough to allocate 6 (yes six!) slots to XMMS2 for this year's Summer of Code. We received many high quality applications and the selection was harder than ever.The selected projects are all very exciting and span all over the xmms2 ... [More] codebase: from deep down the medialib, with an experimental new database backend (S4), through an upgraded iteration of collections (Coll 2.0), all the way up to service clients. In the realm of clients, we will see a new powerful command-line interface (nycli) and an innovative GUI client focused on social metadata (Cloudstream). On top of that, the last project will revolutionarize our IPC layer (GenIPC).Note that most of the projects build on top of last year's GSoC. See the full list of accepted projects (and students) if you want all the details!So, to the accepted students: congratulations and may there be lots of good code written! [Less]

New XMMS2-Scrobbler. Thanks to rafl, the lock file issues should be gone now.

Git is the coolest content versioning system since the birth of bits, and I gave two talks/courses recently: the first at the BarCamp in Lausanne (edition 2), and the second for the local LUG, AKA the GULL. I’ve uploaded the PDF of the slides in ... [More] English and in French, and in case anyone is interested in reusing them, the sources are available (warning: evil Keynote format; I was in a rush, won’t happen again) under the Creative Commons Attribution-Share Alike 2.5 License: sources in English, and in French. And to follow up to the topic of Git, go and read this interesting article about using the Index to do partial commits and this short note about using git-rebase –interactive to rewrite history (not History, yet). PS: I’m quite sure I’m scaring the shit out of my non-tech geek readers, sorry. Stay around though, I will try to split this blog in two (life stuff, bytes stuff) in the future, and I have a few entries about Japan cooking up… [Less]

The screaming groupies disturb my concentration, so I will reluctantly take a few minutes to silence the general hysteria. The secret is no more: we have über-optimized queries in XMMS2! All thanks go to nesciens, who dived in the optimization ... [More] documentation of SQLite to fix some stupid bottlenecks of my query generator. The two most important elements are the use of COLLATION NOCASE for case-insensitive comparison (instead of using LOWER(value), which disabled indexing), and the creation of better indices on the Media table (including collated indices). Let’s get some numbers out! Quick note: in addition to a pair of [key, value] indices (one with BINARY collation and one with NOCASE), he added a pair of [id, key, value] indices. I couldn’t highlight any effect on performance of the latter two, but I left them in for those tests. (Hint: more tests and insight are welcome!) I ran a series of benchmarks with different search patterns. The execution time has been averaged over 100 executions ran with the command time for i in $(seq 100); do $CMD > /dev/null; done. I compared the performance of execution in two versions of XMMS2: default DrKosmos (git hash: f171d33ca13e1715d3b167e8fa958a724eb032ce) optimized DrKosmos (git hash: 94661d22a7437b48c9cb5d4b1cd6483350d0a9a4, nesciens-sqloptims in my tree) The queries used were the following (all matched songs): Q1) artist:Air album:"Moon Safari" Q2) artist:AIR Q3) artist:Air album:"Moon*" Q4) artist~Air In the first set of tests, I used xmms2 as a black-box and ran queries from the CLI. The real execution time was extracted. The data is presented in the following table and graph. Query Standard Optimized Q1 368.25 68.46 Q2 396.11 158.97 Q3 331.23 77.23 Q4 961.69 869.53 The optimized version is clearly faster than the default version, except for the partial matching query (Q4) which is expensive in both cases. In the second set of tests, I ran the same queries directly in the SQLite database to measure the pure query time. The user execution time was extracted in that case. Here comes the data in a table and graph. Query Standard Optimized Q1 168.89 8.52 Q2 168.02 7.16 Q3 164.53 7.43 Q4 203.00 140.97 The difference is even more visible here, although I cannot explain why. The benefit of using indices (in Q1-Q3) is unquestionable. I also benchmarked the performance of running xmms2 info 1 (read all properties from the DB) with both versions, and the execution time was similar. In short, these performance improvements should make it possible to activate find-as-you-type in clients, or at least very responsive searches. Another optimization I would like to implement is searching for a given value in multiple properties (e.g. “artist:Air OR title:Air”). Currently, this is done with expensive JOINs, but it doesn’t have to. I just have to decide in which abstraction layer to improve search in multiple fields (query generator, collections API, etc). It looks like S4 is not as desperately needed as we first though, although it might still make a very interesting GSoC 2008 project (did you apply yet?)! [Less]

As you all know XMMS2 was accepted for Summer of Code even this year. We are always very excited about SoC since it really brings a lot to us and the student.The application process is OPEN now and it will end the 31th of April. Please have a look at our proposed projects page and submit some awesome projects to us!

Google has just announced the mentor organizations for Summer of Code 2008 and we are happy to announce that XMMS2 was selected to participate this year as well.Go to our Summer of Code 2008 portal to get more information.

Let’s keep the blog rolling! This idea popped into my mind the other day, surprisingly not while I was in the shower. I guess it was the combination of my nostalgia for Japan, people talking about daily new XMMS2 clients in #xmms2, and all the fun ... [More] visual stuff (Clutter, WebKit, etc) I saw or heard of at FOSDEM’08. I want an XMMS2 karaoke client! It would run fullscreen on a computer or TV, playing music with XMMS2, displaying sing-along lyrics fetched from the web, on top of random or chosen videos. The queue could be controlled by a song browser on an N810 connected to the main station over Wifi or Bluetooth, much like the neat touchscreens in real-world karaoke rooms (whether Japan is part of the real-world will be discussed in a future article). Alright, what do we need for this project: An awesome music player framework: We have XMMS2! Vocal-less songs: either find MIDI files for songs, or (sexier) run the music through an xform that strips the vocals (buzzwords: signal processing, feature extraction, etc). The DeFX XMMS1 plugin could possibly be reused/ported, as it seems to do precisely that (and a few things more). In case of success, the next step would be to implement custom key adjustment! Microphone mix: mixed in using Jack or PulseAudio? Video playback: gstreamer, VLC, mplayer? Random videos could be fetched from your favourite *Tube website (it can’t be worse than the videos you get in Japanese karaoke — or well in the case of YouTube, perhaps it can). Annotated lyrics: We need lyrics with timestamp annotations to scroll the text and highlight it accordingly. Is there such a free resource online? Google seems to mostly know of “free” sites with karaoke MIDI files, in the animated-GIF-from-the-90’s meaning of “free”. The alternative would be fetching lyrics from a standard website and let users finger-scroll/trigger them by hand while the song is playing. Timestamps could then be saved from the first playback to be replayed the next time! Time: oops, the usual bottleneck. Anyone knows a good resource for free spare time? The idea here would be to only rely on standard data (music, lyrics, videos), in order to not be limited to commercial karaoke CD G or a small repertoire of horrible MIDI files. It would also be fun to hijack XMMS2 onto people’s computer by advertising an karaoke application :-) So will I start working on such a client? Absolutely not. Or not until the technical shortcomings (I’d love to have the vocal removal) are dealt with by Father Christmas, the yeti, or juhovh (or rafl?), whichever comes first. It might not be too big of a deal if DeFX can be reused. We shall see! PS: Ask your mom/gf before you experiment with the fluo paint in the living room. [Less]