Re: [Audacity-devel] EQ response curve speedup patch
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Andrew H. <an...@sc...> - 2014-02-03 06:38:39
|
On 2/2/2014 7:06 PM, Martyn Shaw wrote: > Hi Andrew > > Thanks for your work on this. > > Can you please give an example where this is slow updating? I've > always found the speed that the green curve updates very acceptable, > even full-screen. And I don't have a particularly fast machine. My every day machine is no speed demon. I had to quantify what I was seeing. I put in a quick FPS counter and here are the results. (It only updates when the mouse is dragging) Log scale, full screen 1920x1200, 6 point square wave (0, -24, -24, 24, 24, 0), dragging one point around. Debug: Old Method 3-6fps Debug: New Method 20-27fps Release: Old Method 8-11fps Release: New Method 28-37fps When I noticed the slowness, I was in Debug mode BTW. Yes it's much better in Release, but I can still imagine some machines bogging down well below my numbers. > Do you have a high or low 'Length of Filter'? Are you looking at > ripples at high or low frequencies? Did not change the filter. Though I did after reading this. (see below) I was looking at the low frequencies in log view. > At LF (say a HPF @ 100Hz and messing with a point in the cutoff, > 'Length of Filter' set high) I find both red and green curves very > responsive (although green clearly more representative). If you're seeing a red line it means compare is on and both methods are active. When either method is active by itself, it draws a green line. > So I currently don't see any advantage in these approximations. > > TTFN > Martyn > Full screen log view, it seems to stop using the offending code around 697hz, length of filter or any other setting seems to have little to no effect on its usage. It could be improved as well using a 3 point curve, to smooth out the sharp edges, as well as holding previous calculations between points. I was just really surprised to see line drawing code taking so much of the processor. More than the FFT code? Looking down the road. Say for instance the EQ dialog is modeless while some other processing is going on . (I.e. EQ ing what you hear) It could easily steal the CPU from that process and cause glitches. New patch attached. Fixes a few things, adds QUICKDRAWRESPONSEFPS define for ugly FPS code Andrew Hallendorff |