On 23-Sep-08, at 6:12 PM, Russell Ryan wrote:

> Hi all,
>
> I wrote up a spec for an idea I've had for fixing some of the waveform
> summary thread issues we've seen.
>
> http://mixxx.org/wiki/doku.php/waveform_thread_refactor
>
> There were two bugs mentioning that after a while the waveform view
> would no longer render waveforms, while the rest of Mixxx was
> responsive. It looks like this was a bug with the waveform  
> downsampling
> code where the thread would walk into an infinite loop. While that's
> been patched, there are still some reasons for this change.
>
> First, if there is a problem with waveform downsampling that causes a
> similar infinite loop in the future, if it's contained to one thread  
> per
> TrackInfoObject, then the next time someone queues a track, the  
> stalled
> thread goes away, and a new one starts on the track that was just  
> queued.

This is great because it'll mean the waveform view will always  
immediately start rendering when a song is loaded. It'll also save  
your CPU from rendering/downsampling songs that have been unloaded,  
like when you're quickly loading and previewing many tracks that are  
in your library. I think these changes will be a big win for keeping  
Mixxx snappy and make the user experience better in general.

>
> Second, it solves the issue of who "owns" the waveform buffers. If the
> per-track WaveSummary object is in charge, then it can also be in  
> charge
> of deletion, etc.

Sounds good. I think this OO refactoring makes sense and will improve  
modularity.

One thing I'd like to clarify for anyone reading is that the  
WaveSummary threads (that will spawned from TrackInfoObjects) won't  
actually be created until a song is loaded. So while we'll have a  
whole library full of TrackInfoObjects, there'll only be a maximum of  
two WaveSummary threads ever in existence.

Question: Will the WaveSummary objects be created when a  
TrackInfoObject is loaded into a player? (I'm worried about memory  
usage since we have a whole library of TrackInfoObjects.) Also, where  
is the WaveSummary data stored (ie. the little waveform preview  
samples) at runtime now?  I'm curious to see how the memory usage of  
our existing code scales with library size...

Thanks,
Albert


>
>
> Comments? Do we need this?
>
> I cut a branch for getting this functionality working, it's named
> rryan-wavesummary-refactor. I'm probably a little more than half-done.
>
> RJ
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Mixxx-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mixxx-devel


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Mixxx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mixxx-devel

Reply via email to