Re: [Protux-devel] Re: Peak revisited

[Luciano Giordana]

I already tested and it works pretty fine. Congratulations.
I will merge it into 0.17.9, and add you into the team list

I had only to add a delete tempRAMBuffer at the end of build(), to
avoid a mem leak

please, talk to reinhard to get a CVS account into protux repository

[]s


On Tuesday 17 June 2003 06:42 pm, you wrote:
> The peak file I send you with my email today does this thing  (using the
> MCD). I will look tomorow if there can be small refinements, but in this
> state, it should work.
>
> Hmm, well a small explenation. I scan the whole file ones with the MCD
> zoomstep[hzoom] and store it in a tempRAMBuffer (this lvl isn't used by
> RAMBuffer, so I had to made a temp buffer). This temp buffer is used to
> store the values in RAMBuffer which is only a matter of a fast CPU and fast
> memory. Scanning a 160 MB audio file takes 25 seconds here (importing a
> wav), previous it was 5 minutes. (celeron 800, 256 MB Memory)
> This is what you ment to be done, isn't it? ;)
>
> And the email problems seems to be solved also.
>
> Greetz,
>
> Remon
>
> Op woensdag 18 juni 2003 01:15, schreef Luciano Giordana:
> > On Tuesday 17 June 2003 05:55 pm, you wrote:
> > > Hi Luciano,
> > >
> > > After a busy week at my parents home (had some kind of concert, so I
> > > was hard studying my pieces of music ;) ) I looked again at the peak
> > > file.
> > >
> > > I have a few questions. Is it necesary to store peak info in a peak
> > > file? With large audio files, it consumes much memory and it isn't
> > > really faster. The only benefit I see is that there's no hard disk IO
> > > when recording music.
> >
> > Yes. See SPECIFICATIONS #5
> > If the peaks arent prebufferes, fast drawing would be slowed down, since
> > HD reads are much slower than RAM read
> >
> > > Also, zoomlvl 64 is stated twice??
> >
> > It shouldnt, I will check it
> >
> > > The first bottleneck I encountered was the "blockPos %
> > > zoomStep[hzoom]==0" statement. This consumes a lot of CPU power.
> > > The other bottelneck is seeking through a file. With this new peak
> > > file, this is done only once, with a stepwidht of 16, reducing the time
> > > of seeking16 times :). This gives also a good waveform as far as I can
> > > see. It can also be 8, but this consumes much more CPU power.
> >
> > You have sent another email talking about a modified Peak class. I
> > answered but that time we had that problem of denyed IP relay.
> >
> > I looked at that Peak.cc and found cool the optimization, but it is not
> > the ideal. The best way is to find the maximum common divisor for zoom
> > levels and scan the audio only once, jumping all steps smaller than the
> > MCD. This way , we find all peak images at once. If it is what you have
> > done now, thanks a lot. Please send me so I can patch the class
> >
> > > I hope you can do something with it. At least for testing purpose :).
> > > It has now a speedup of at least 13 times. This is even more for
> > > smaller files.
> >
> > Surely I will,  thanks again
> >
> > > Greetz,
> > >
> > > Remon

-- 
Best Regards
--
Luciano Giordana - Musician - Certified Java/GNU C++ Developer - Free Software 
Evangelist
Project Mustux - http://www.freesoftware.fsf.org/mustux
-- Once Palladium is up and running , I will become a hacker --