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

[Luciano Giordana]

> total size of all the buffers. If there is no posability to take care of
> this, there's is a change that the total amount of buffers exceeds the
> size of the main memory, causing the buffers to be swapped.

Surely. It is better to create a separated class for DiskStream  handling.
But the calls for Audio must be transparent (or very little adapted), so we 
must keep the interface.
I mean, Audio clients (such AudioClip and Song) must not know about disk 
streams.

> Implementing the same buffer logic in DiskStream class, and attaching the
> Audio Objects to the class you will receive the same results, but with the
> possebility to make control stuff in DiskStream after 0.30

precisely

>
> Why do this? Well, all the coding which has to do with audioSources, (with
> filters in mind) will already be done in the right way.

Media filters, you mean ? Those already pre-coded are real-time filters .

> For example: opening an audioSource an seeking to a specific point:
> AudioSource->seek(int point) instead of
> File file = AudioSource file(.,point,seek)
> Or something like that.
>
> Ehm, hopefully I do not miss a point. This way it is easyer to implement
> things afterwards in a DiskStream class withtout changing all the
> audioSource acces methods?
>
> I hope, I made clear what I have in mind.

much more clear ! :-)

>
> Greetings,
>
> Remon
>
> > 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. --
> >
> >
> > _______________________________________________
> > 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. --