On Mon, 31 Jan 2000, Paul Barton-Davis wrote:
> 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 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.
It sounds to me like any existing file system is just going to get in
your way. What you need is a simple filesystem that just has one file,
and it takes up the whole partition, can't be truncated or extended,
no index, no inodes, no directories, no permissions, nothing. Just
straight I/O to the disk. If this partition exists on a dedicated disk
you'll be completely in control of all seeking. You can keep any
indices you need in a file on another partition.
This really wouldn't be very hard to write - it's sort of the "null
filesystem" and it would fit nicely into the vfs model. You could
call it "raw":
mount -t raw /dev/hdb1 /muchmusic
You can make it as a module so you don't have to patch the kernel:
insmod raw.o
The easiest way to make it would be to take the simplest of the existing
filesystems (minix I think) and gut it. You should be left with just a
couple of hundred lines when you're finished, mostly lists of null file
operations, etc. The result would be really useful.
All in my very humble opinion, of course.
-- Daniel- 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 : Mon Feb 07 2000 - 21:00:11 EST