Subject: Re: [linux-audio-dev] tricks wanted for buffer cache optimization
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: ma tammi 31 2000 - 19:50:49 EST
In message <20000131201057Z3828-9029+3765_AT_nic.funet.fi>you write:
>>*nice* to get true, "instant" (i.e. faster than typical human physical
>>response) tape positioning regardless of the number of tracks or file size.
>
>If you ask me there is no need to get that fast tape positionings
>for interactive use. Sequencer is different and then we know where to
>jump next. Is this sequencing a problem?
no. i think that for now, i've decided to go with a temporary pause in
activity when you use the transport mechanism to move outside the
currently in-memory region. the delay will be between 0.5 and 4
seconds, if the files are on their own disk and are fairly contiguous
in terms of block allocation.
>>cache to do my work for me, partly so that Nemesys can't possibly
>>complain about patent infringment :)
>
>I don't even want to read that patent, do I miss anything?
its just a stupid software patent for read-ahead. they grab the first
(5?) seconds of a sample before playback. sigh.
>Why you have to restrict to Linux's virtual memory?
>What is the problem of making your own prefetching VM system for
>audiofiles the same way it is done for normal files in OS'es?
because whether you like it or not, the buffer cache is going to be
doing its thing anyway. i'd rather get it to work for us than
duplicate it *and* have it working against us.
that is, unless you use 2.3's new rawio devices. there are lots of
good arguments why thats a bad idea, and it doesn't get rid of the
seek problem anyway.
--p
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:27 EST