[lkml]   [2000]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: advice requested re: huge files and/or disk seeking
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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:56    [W:0.031 / U:0.572 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site