Messages in this thread | | | From | Daniel Phillips <> | Subject | Re: advice requested re: huge files and/or disk seeking | Date | Sat, 5 Feb 2000 08:30:14 +0100 |
| |
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/
| |