Re: [Protux-devel] Re: Buffered micro view

[Luciano Giordana]

I thought it was a Linux problem. But it is indeed a good idea.

Let just remember that there is a "optimization" phase for protux, after 0.30 
release
I am trying to follow the paradigm : make it work then make it work better, so 
we avoid
to spend time on optimizating stuff when we dont have already all basic stuff 
we need even pre-coded.

Anyway, I believe that that would be anought to work on Audio class to perform 
such streams, by improving the read_audio_frag / write_audio_frag methods.



On Friday 18 July 2003 05:27 am, Remon Sijrier wrote:
> Hi,
>
> Lots of time to think :)
> Result: You can forget all about it if protux decide to use a "DiskStream"
> class.
>
> One of the benefits is that all audio information for micro zoom lvl's is
> already in small buffers in main memory, so no extra hard disk acces voor
> micro view mode.
>
> Disadvantage: more memory consumption.
>
> Why using a DiskStream class?
> 1. Reading and writing files done via the O.S. is also done via small
> buffers, but very slow compared to for example writing/reading a file of 1
> MB at once, making it possible to handle much more audiostreams at once.
>
> 2. Central place for opening/closing/reading/writing a file. When
> playing/recording in micro view, one file is opened for playing and the
> same file with exact the same information is again opened/read (seaked
> through) for the micro view drawing.
>
> 3. Your hard drive last longer :)
>
> Remon
>
> P.S. This is of course not my'n invention.  I read first about it on the
> ardour dev. list. I looked at some code and that was almost the same thing
> I had in mind.
>
> Op donderdag 17 juli 2003 20:15, schreef Luciano Giordana:
> > Remon has said some emails ago
> >
> > > 4. Peak drawing: Interesting thing, it's maybe an idea to use a/the
> > > peakbuffer for micro-view as well. (I looked already for this, and
> > > think it'll be much better) Peakbuffer is now ~ 1/20 of the actuall
> > > audio size, a buffer containing the "actuall peaks" is even smaller.
> > > Using this very small buffer, it is possible to draw a (close to)
> > > perfect waveform in microview. This REDUCES hard disk acces a LOT
> > > (infinite, to be precise :) ). It is maybe even possible to draw the
> > > waveform for zoomLevels up to lvl 20+ with this buffer. For larger
> > > levels CPU-power consumption is getting problematic, but putting this
> > > higer levels in a buffer requires only a small amount of memory. Just
> > > an idea I got while doing peakbuildig stuff. Already measured some
> > > things. If you think this is something to be worked out, then I will do
> > > some more measurements.
> > > 4a. Make peak building threaded. :) (Maybe something for me ?)
> >
> > Sounds interesting, but I have a question. In a 1:1 hzoom level, would I
> > have to buffer ALL the samples? Maybe I missed something. Because the
> > buffer is the image of all peaks of audio source for a given level. If I
> > buffer 1:1, I will have to buffer all samples, which is bad. Thats why I
> > decided to read directly from audio when hzoom level is below 1:64 (RFC)
> >
> >
> >
> > _______________________________________________
> > Protux-devel mailing list
> > address@hidden
> > http://mail.nongnu.org/mailman/listinfo/protux-devel
>
> _______________________________________________
> Protux-devel mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/protux-devel

-- 
Best Regards
--
Luciano Giordana - Musician - Certified Java/GNU C++ Developer - Free Software 
Evangelist
Project Mustux - http://www.freesoftware.fsf.org/mustux
-- GNU/Linux adoption grew 65% only this yer. Smile : we're winning. --