Subject: [linux-audio-dev] design question for HDR
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Mon Apr 03 2000 - 02:35:41 EEST
It increasingly appears to me that Linux, even with Ultra-2 SCSI
disks, cannot keep up the required data flow for 24 channel recording
when the channels go to *individual files* instead of being
interleaved.
The jitter in the disk seek+read times is too great - up to a factor
of 5, with all sorts of possible causes (other disk I/O from paging,
buffer cache flushing, etc. etc.)
Things go badly wrong when the read-ahead thread fails to keep ahead
of the audio thread. It only takes one single mlock/read to take, say,
4 times longer than it normally does, and everything starts spiralling
downhill. How come ? Well, if track N takes 4 times too long, the
audio thread has moved along in the meantime, and used more of what
was already read-ahead for track N+1. Thus, track N+1 also takes
longer than it "should" (because of the extra data to read). As a
result, track N+2 takes longer as well, and so on. Pretty soon, the
amount of data each track needs to mlock gets larger than can be done
within the deadlines set by the audio h/w. Then its all over. (*)
There is no doubt that it could work with an interleaved data stream,
since there would be almost no disk seeking to speak of. The
interleaving would not have to be at the sample level, it could be on
a block-of-samples level. Either way, we end up with files that are
very hard to use for both varispeed and editing, whether
non-destructive or not. Imagine cutting out a section of a single
track. If you do it destructively, you have to rewrite the entire file
afer the start of the cut; if you do it non-destructively, you start
to create disk seeks for the playback-from-a-playlist mechanism as it
has to skip over sections of the file that were cut, and then seek
back to the start of them for the non-cut tracks.
Therefore, I feel that this (interleaving) is a crazy design for an
HDR system, even though I suspect that several existing HDR systems
probably use it. I welcome comments and ideas since I am pretty
confused and dispirited about what to do. Perhaps, as happens so
often, I am just missing something obvious.
--p
(*) would a heuristic work here ? If the amount to read-ahead exceeds
a certain amount, back off to a smaller amount, and hope that we
can get back to being sufficiently ahead of the audio thread soon.
I'll try it.
This archive was generated by hypermail 2b28 : Mon Apr 03 2000 - 03:04:49 EEST