Re: Rhythmbox Predictive Playback - Weekly Report

["Charlotte Curtis" <c f curtis gmail com>]

Hi GNOME SoCers,

Next Tuesday is a holiday for me (Canada Day), and some lucky folks
get the Monday off as well, so I'm going to be heading out of internet
range for a few days to enjoy the start of summer.  Hence, I'm sending
this report early.

Last week was a learning experience for me: convincing Python to
launch executables without causing the entire Rhythmbox GUI to lock
up.  I tried a number of things - threads caused problems because I
was launching the program from a loop and I ended up with hundreds of
little spawned processes, whereas I only wanted one to go at a time.

Next I tried the gobject.spawn_async function together with
gobject.child_watch_add, and it took me a long time to realize that
child_watch_add only works with a main loop running (and apparently it
needs one in the plugin itself, even though presumably Rhythmbox is
running a main loop as well).

If I give my plugin its own mainloop, which is started when I execute
the process and then stopped when the process completes, my plugin
works quite well.  However, my mentor and the Rhythmbox devs agree
that a plugin having its own mainloop is a Bad Idea that will likely
cause problems down the road when I least expect it.

My task next week will be to try to get rid of this mainloop.  This
will likely require getting rid of the loop that is calling the
functions, and instead pass around an iterator so that iter.next can
be called when the process completes.  It's an interesting problem,
and one that I didn't expect at all when I started this project.  Good
times.

Charlotte

On Mon, Jun 23, 2008 at 9:05 AM, Charlotte Curtis <c f curtis gmail com> wrote:
> Good morning everyone,
>
> Last week (week four) I pretty much settled upon a feature extraction
> algorithm that I am happy with.  It only uses the middle 30 seconds of
> each song which could obviously result in inaccuracies, but doing so
> reduces my computation speed significantly - to about 0.5 seconds per
> song (in mp3 format) on a fast computer.
>
> I am going to move on to my actual GNOME part of this project: making
> the Rhythmbox plugin to call the feature extractor and create
> automatic playlists.  I had thought to spend some more time with the
> feature extractor to make it write to a database rather than a single
> feature file per song, but I think it would be a good idea (as someone
> suggested on my blog) to get the plugin working first, and then go
> back and make things pretty/optimized.
>
> On Mon, Jun 16, 2008 at 9:36 AM, Charlotte Curtis <c f curtis gmail com> wrote:
>> Week Three was quite productive for me.  I implemented a feature
>> extraction algorithm using Marsyas that was very successful at last
>> years' music information retrieval competition.  I did switch from
>> Python to C++, as I saw a significant speed increase, even when
>> calling executables from Python code.  I had a minor setback on Friday
>> when I managed to overwrite my source code, but it turned out to be
>> not a big deal to re-write, as I had learned how the system works.
>>
>> This week I will work on optimizing the code for speed.  At present, I
>> am extracting features for the entire song (most researchers use a
>> 30-second segment), and on my Q6600 the process takes about 4.4
>> seconds per song.  My old P4 was about 2.2 times slower (based on a
>> test that was timed prior to old computer death and repeated on the
>> new computer), so I cannot expect that people will want to spend 10
>> seconds or more per song extracting features.  My goal is 2 seconds
>> (on a moderate processor, tested on my 1.1 Ghz Pentium M), and if I
>> can get less than that I will be happy.
>>
>> That's about it for this week,
>>
>> Charlotte
>>
>> On Mon, Jun 9, 2008 at 9:16 AM, Charlotte Curtis <c f curtis gmail com> wrote:
>>> I like how people are doing a single thread for all their reports, so
>>> I'm going to start doing the same.  Wish I'd thought of it last
>>> week...
>>>
>>> My week began fairly well - I had given myself a deadline of Friday to
>>> choose an audio processing library, but after building sample
>>> applications and messing around with a few, I decided on Tuesday that
>>> I really liked Marsyas.  Not only is Marsyas a library specifically
>>> aimed at audio analysis applications, it also has some python
>>> bindings, which means I might be able to do everything within a python
>>> plugin, provided it's fast enough.  At the very least, I can build and
>>> test algorithms in python, and if I need a speed increase, re-create
>>> it in C++.
>>>
>>> Coding became a little bit more difficult on Wednesday morning when my
>>> CPU overheated and refused to fire up again.  Now, I could have gone
>>> and found a used P4 for sale somewhere, but then I would have had to
>>> wait for shipping and all... and besides, it seemed like fate - I
>>> bought the computer in September 2003 when I began my undergrad, and
>>> it died just over a month after I graduated.  In any case, I live
>>> right down the street from (IMO) the best computer shop in Canada
>>> (canadacomputers.com!), so I spec'd out a new system, whipped out my
>>> shiny new google mastercard, and spent the day on Thursday building,
>>> installing, and setting up a new computer.
>>>
>>> On Friday I managed to get some more work done on my project (four
>>> times faster!) - I learned a little about how to use SWIG, and I added
>>> bindings to some datatypes of Marsyas that were missing.  The Marsyas
>>> devs have been very helpful thus far and I'm glad that I can
>>> contribute a little back to them as I work on my project.
>>>
>>> Cheers,
>>>
>>> Charlotte
>>>
>>
>