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

[Remon Sijrier]

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