Subject: Re: [linux-audio-dev] hdr disk throughput
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Tue Mar 14 2000 - 05:21:27 EST
>> i tried your program and got 14.2MB/sec throughput. I also noticed
>> that your buffer size was 1MB, which means that my initial concern
>> about the gap between the read/write locations is irrelevant. Thanks a
>> lot for checking this out. Now I have to work out a buffering scheme
>> that works :)
>
>:-)
>
>In practise, you should be able to vary the hard disk buffer size
>independently of everything else, so you could tune it to best
>performance for each machine (run some tests to see which is best?)
Well, size is not quite the issue. Its a bit more subtle than that.
Ardour uses mmap to avoid data copying. It mmaps both the audio
interface buffer(s) and the per-track files. It doesn't work to use
the mapped regions directly, because mmap cannot be tuned to do what
we need in terms of read-ahead, and more importantly, operations on a
mapped file can result in disk I/O, which is not a good idea in a
real-time thread.
So there is are 2 intermediate ringbuffers for each track. For
playback, the tape/recorder thread reads from one ringbuffer, while
the "tape butler" thread copies from the mapped region into the
ringbuffer. the buffer is lock free, and thread safe.
For recording, the tape/recorder thread writes into a ringbuffer, and
the "tape butler" thread copies that back to the mapped disk file.
Until a few days ago, the tape butler thread only operated in one
direction per track i.e. the track is either capturing data or playing
back.
This scheme appeared to work fine until I realized that I need the
playback ringbuffer to be filled all the time even if the track in
question is currently recording. Then I further realized that for
punch in/out, this is also exactly what we need, since we can do the
cross-fade between the old and new material directly onto the existing
material from the playback ringbuffer, and then write the result back
to disk (pretty much like your overwrite example, except with some
active mixing going on).
This then begs the question: why have two copies of the data, one in
the capture ringbuffer and one in the playback ringbuffer - its much
more obvious to have just one, and copy it to the audio interface for
playback and overwrite/mix it for capture.
Ah, not so fast - the desired position of the ringbuffer relative to
the disk file is different for playback and capture. OK, just make it
big enough to cover them both, right ? Perhaps, but I am concerned
that there are situations where the activities of the tape butler
(trying to refill the ringbuffer and/or (hopefully just or) flush it
back to disk) will mess things up.
Well, I am currently working on this the design for this stuff. Its
non-trivial, I think.
>Maybe it's worth writing a special file system for this kind of
>thing.
Yes, this has been suggested. Someone on the linux-kernel list
suggested to me starting with the minix fs, since its about the
simplest one there is, and ripping it to pieces so that all was left
was one or some other fixed number of files in the partition. they
claimed that the code would be very simple.
However, since i can apparently easily get the disk seek and i/o
performance that i need even from non-dedicated partitions, my
incentive to do this has evaporated :)
--p
This archive was generated by hypermail 2b28 : Tue Mar 14 2000 - 12:54:30 EST