Subject: Re: [Fwd: [linux-audio-dev] info point on linux hdr]
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Sat Apr 15 2000 - 14:38:55 EEST
>It would be interesting to compare filesystem latencies in the HDrecording
>case. As said it's amazing how long the disk thread can get blocked during a
>large buffer flush/metadata update, on a PII I saw watched the disk thread
>blocking for several seconds (up 8 secs in the worst case).
>That means at a datarate of 200kb/sec per audio tracks sometimes you would
>need up to 2MB ringbuffer per track. Multiply this value with 50 tracks , then
>you get 100MB of precious RAM wasted for doing only buffering.
>I am convinced that we can do the job with 0.5MB per track when using RAW IO.
>(Windoze hdrecording apps seems to work well with these amounts of buffering).
Well, first of all, as I've mentioned already on LAD, by preallocating
the files, this problem appears to vanish. Second, its unclear whether
the Windows/MacOS apps do preallocation or not (though it is clear
that they are very fragmentation sensitive). Thirdly, the amount of
user-space buffering thats needed is not just a function of jitter in
the apparent disk throughput rate.
Benno and I have been through this before with respect to audio h/w
buffer usage, and we concluded that its very advantageous to use 3
fragments there, precisely to protect against jitter. I think that the
same applies here - you want the user space buffer divided into at
least 3 "fragments". When fragment N is in use by the audio thread,
the "previous" fragment is being handled by the butler thread (for
read-ahead and flush to disk). In theory, 2 would be enough, but if
for any reason, the butler is ever slowed down for one iteration, so
that it fails to finish processing its buffer before the audio thread
needs it again, having 3 provides a way to avoid problems.
If thats correct, then we next have to look at the appropriate size of
those fragments. Since they are intended to correspond to single disk
i/o requests, they need to be sized so that we get maximal disk
throughput. My experiments have suggested that a 256kB disk i/o
request seems to be the smallest size that gives the maximal
throughput. If so, then the lower bound on the amount of buffering is
not really "optional", but is 3 x 256kB.
You can substitute other numbers in here for the number of fragments
and the size of the disk i/o requests, but the principle will remain:
the amount of buffering is not really a function of time (seconds),
but of the way you subdivide the buffer for disk i/o and the optimal
disk i/o request size.
--p
This archive was generated by hypermail 2b28 : Sat Apr 15 2000 - 15:05:09 EEST