advice requested re: huge files and/or disk seeking

[Paul Barton-Davis]

i am working on a multitrack hard-disk recorder for ALSA. when i say
multitrack, i don't mean "record one track or two, then add
another". i mean "record 24+ tracks of 24bit audio at 96kHz sample
rate at the same time".

i face a problem or two. a 4GB file size limit means that i could
never fit more than about 7-3/4 minutes of audio into any one
file. thats bad, very bad.

instead, and also prompted by the fact that the audio interface (the
RME Digi9652, a pure digital interface with 26 input channels and 26
output channels) does not interleave its data, i have taken the
obvious approach of storing each track in its own file.

this works fine for recording, but playback is *hard* to do if we want
low latency operation (where low latency means queing less than, oh,
20ms worth of data in the h/w buffer). why is it hard ? because seek
times on modern disks are at least 4.5ms, and when we have to seek
across 24+ files, which happens from time to time as the buffer cache
does it stuff, we lose bigtime.

one option is to pray for a large file size limit, and then interleave
the data. last thing i knew, this was still an unincorporated kernel
patch. bad choice from my perspective, if thats still true.

i can check this fairly easily, but i wanted to put the problem to the
brilliant minds here, and see if anyone has any thoughts. the goal is
to get "instant" response to "tape transport" controls - some clicks
on the rewind button, and when they let go, the time until we're ready
to start playing again is less than typical human physical response
times. in that time, we (may) have to seek and load in about 1-3secs
worth of data from the N files used to hold the audio.

any comments or opinions ? i am not on linux-kernel, so please include
a personal reply.

--p

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo en vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/