Re: [Audacity-devel] Raspberry Pi

[Richard A. <ri...@au...>]

On Mon, 12 Aug 2013 00:32:55 +0100
Martyn Shaw <mar...@gm...> wrote:
> When I run it I get the interface, Generate -> Chirp -> OK and get a 
> progress bar, a generated waveform, and then a disappearance of that 
> and an 'Edit' item of 'Undo Track Remove', I don't know why but
> that's not right!
Is this in 2.0.3? 2.0.3 on Linux doesn't do this for me, so it may be
we have actually fixed something since 2.0.1!

> > What is noticeable to me is that we use a lot (in comparative
> > terms) of CPU when audacity is idle, i.e. doing nothing, just the
> > GUI open. I haven't tried to profile what is using the cycles, but
> > in the system task list we are always top ...
> 
> Yes, it's using 35-40% of resources here just sitting there.
> 
> > I'm hoping that fixing this would also make an improvement (although
> > lesser) to other platforms. This is without James's fix for the
> > button painting, which is the sort of thing which can make an
> > larger-than-expected difference to the Pi which has a pretty
> > slow/CPU intensive graphics stack by modern standards.
> 
> So you think it's the timers?  I've never really looked at those.
> Any ideas on reducing the load?
To be honest I think it's time to break out the profiler, although I
can't claim to know hardly anything about the practicalities. Google
gives me some links like:

http://stackoverflow.com/questions/2229336/linux-application-profiling
http://www.baptiste-wicht.com/2011/07/profile-applications-linux-perf-tools/
https://perf.wiki.kernel.org/index.php/Tutorial
http://www.pixelbeat.org/programming/profiling/

which should get what we are hoping for - a view of the functions which
audacity spends most of it's time in.

My gut feelings are either screen
paints or string translations (or a combination - each time something
paints, it re-translates the string, which causes a disk read) but this
is pure guesswork without a profiler output.

Richard