I am a significant way along completing a high end audio recorder for
Linux (high end: 26+ channels of 32 bit audio).
I have been holed up (as well as held up) for the last few weeks
trying to design a new buffering scheme for the data after I realized
that my old one had a fatal application-level design error.
I thought I had finished the new design, but have found that it
doesn't perform as well as the old one, and I suspect that this is
partly to do with the different way I am using mmap(2) in the new one.
The application level requirements: suppose that we have a file of
recorded data. We need to read-ahead a certain amount to ensure that
the audio thread never blocks waiting for data to come from the disk
(seek time issues). At the same time, certain tracks, from time to
time, may have data recorded to them that needs to be written back to
disk. Note that this is *not* a bi-state model: all tracks must always
be read-ahead, some tracks have recorded data.
My current model centers around a ringbuffer with mmap-backing. That
is, a "butler thread" mmaps the file(s), and copies from the the map
into the ringbuffer. Meanwhile, the "audio thread" reads from the
ringbuffer, and sometimes writes back into it. If the butler thread
finds that the audio thread has written some data, it copies it back
into the mmapped region before moving the map in order to do the next
read-ahead. So the butler thread essentially does this:
for each file
if (recorded data waiting) {
copy data from ringbuffer to mmap
}
move mmap
read data from mmap to ringbuffer
}
At the moment, I map the region of the file between the start of any
currently recorded data and the end of the datathat has been
read-ahead, since this represents the region of the file that could
potentially be written back to. But this is a moderately large area:
if I use 1sec of read-ahead, that can be up to 1MB per track, or 26MB
of mmapped data (for 26 tracks), and the mapped region is constantly
moving around (say, every 20msec - could be more often, could be less).
Overall, we are looking at requiring up to 9MB/sec effective streaming
rate (visible only after buffering in the ringbuffer) both to and from
the disk (18MB/sec total throughput) for 24 tracks.
Its not clear to me how best to utilize the interaction between
mmap(2) and the buffer cache to get optimal performance for this kind
of thing. I would welcome any comments or ideas.
--p
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:30 EST