Hey Bill, I put the last hunk from your patch into 1.8 (the list iterator optimization). The other stuff depends on the play button being a good indicator of whether or not the engine should be processing audio, and that's not always true. Eg. You can drag the waveform when playback is paused, and the engine needs to process that. Vinyl control is also implemented in 1.6-1.8 in a bit of a janky way where the play button is off and playback is entirely driven by the "scratch" ControlObject. Maybe checking the current rate from RateControl would be a better indicator?
(There will even be problems with that approach once effects are in. A delay effect would require the engine to be processing after playback motion has stopped.) Thanks, Albert On Tue, May 18, 2010 at 1:22 AM, Bill Good <[email protected]> wrote: > If anyone's interested -- > I spent a few hours this evening looking at decreasing mixxx's CPU utilization > while idle -- currently, on my machine, I have two mixxx threads hover at > around 15% cpu utilization while idle (waveform rendering on, no decks loaded, > mixxx just initialized) (this is in trunk). With the attached patch, one of > those threads drops to between 7 and 8% (~50% improvement). > > What I've done: > First was to make the engine stop processing nothing. Trunk currently sends > buffers full of 0.0f's through the eq's, faders, etc. These aren't > particularly > computationally expensive (as I learned in the process of all this), but they > account for a few % utilization. I solve this by giving enginebuffer a public > isPlaying method (as enginebuffer has access to the play button), and if both > buffers aren't playing I simply fill the buffers to the sound device with > zeros > and jump out of the enginemaster::process method. Not filling the buffers with > zeros leads to nasty things when one pauses a deck, leaving no decks playing; > i.e. the previous samples are simply played continuously until play is clicked > again. > After this didn't do me a whole lot of good (1-2% utilization saved), I moved > on to sounddeviceportaudio::callbackProcess, which is/was a bit of a hog > according to profiling. Specifically, the QListIterator stuff seems like it > either likes allocating and copying memory, or maybe just sits and fires > NOOP... either way, according to the qt docs using qlist::at() is faster and > no more dangerous (in regards to thread safety) than using an iterator, so I > modified code to do so. > > Anyway, the first bit (disabling enginemaster processing on silence) is worth > about 2% CPU utilization on idle on my machine, and the second bit is worth > about 5% CPU utilization (on idle, on my machine) -- both numbers can be +-2%. > > Giant disclaimer: I don't deem this patch in any way ready or proper to go to > trunk, it may burn your house down, set your car on fire, or eat all your > vinyl. But if anyone else is interested in getting mixxx's cpu usage on idle > down (ideally to 0!), this might be something to reference in the future. > > Thanks to Sean for pointing me in the right direction in regards to profiling. > > Bill > > ------------------------------------------------------------------------------ > > > _______________________________________________ > Mixxx-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mixxx-devel > > ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
