Re: [Audacity-devel] Re: Audacity CPU load
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Joshua H. <jo...@re...> - 2003-03-12 05:55:13
|
On Mon, 2003-03-10 at 23:19, Dominic Mazzoni wrote: > Joshua Haberman wrote: > > ~3% CPU with 1 track > > ~20% CPU with 2 tracks > > ~50% CPU with 3 tracks (!!) > > This growth is not good, what could be causing this? > > OK, I figured it out. A small seemingly insignificant line of code > didn't make it from the original AudioIO to the new rewrites. The > problem is that FillBuffers computes how much buffer space is > available, retrieves that much, and then goes to sleep. With one > or two tracks, it sleeps for much longer than the time it took to > grab that audio data. But with many tracks, it may take quite a > while to load the same amount of audio from all of the tracks, then > it sleeps only a short while, then wakes up and loads more audio. I didn't include this optimization because I didn't understand why exactly it was necessary and I didn't want to include it until we had explored possible alternatives. What you have described makes sense, and it sounds like a good optimization. > Josh, if you want to fiddle with this in the next 24 hours, > great, otherwise I can check in a fix tomorrow night. Let me > know. I would love to, but I don't have time in the near future. I have a busy week this week and on Saturday I'm leaving town for a week without access to email. > I'd also like to cut down on the "Play" button latency by > only having it fill the buffers partially at first. Maybe > we could use 0.5 sec * (number of tracks) as a rule of thumb. > That should scale down to a 333 MHz Pentium II, give or take > a few bogomips. It seems this would increase the chance of getting dropouts. It requires the disk thread to read 4.5 seconds of audio on all tracks in 0.5 seconds, which is far more demanding than the current behavior which never requires the ability to read more than 1 second per second. > Actually I just realized that for the audio-filling thread > to really be correct, it actually shouldn't sleep if it's > "falling behind". It sleeps for ten milliseconds. I cannot imagine a situation where these ten milliseconds would be enough to cause problems; if the disk throughput is this close to being used to capacity then any slight outside factors (like other programs doing disk i/o) will cause audio to glitch also. > For now, just setting an arbitrary threshold like filling the > buffers only when they need at least 2 seconds will improve > performance dramatically for most users. This seems like a reasonable optimization, and it is simple to implement. > This should definitely be used during recording, too. It's > a little tricky since we need to make sure that FillBuffers > completely empties the buffers when the user presses "stop" > (but not for a hard stop). Josh, will you either do this, > or at least help me think through the logic, since you have > the AudioIO code in your head best at this point? I will definitely be thinking about this and brainstorming the simplest and best way to accomplish these things. Josh |