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

[Remon Sijrier]

Hi,

> 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.

Of course, optimizing thing's which are barely coded doesn't make sense.

>
> 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.
>
Oke, the logic using a buffer and keeping it consistent with the file on
the hard disk is the same if you do it in Audio class, but if you keep the
logic in Audio class, it is hard (for example) to measure/control the
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.

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

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.

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.

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
>