Messages in this thread | | | Date | Sat, 24 Jul 1999 18:32:15 +0200 | From | David Olofson <> | Subject | Re: real-time threaded IO with low latency (audio) |
| |
yodaiken@chelm.cs.nmt.edu wrote: (...) > > disk i/o > > What do you want here? The interesting problem is reading from a disk at a > fixed rate, e.g. for display of video or for sound, but this seems > like a buffering problem more than anything else. Writing data is only > a buffering problem. You are almost always better using a smart very > much non-rt file/ i/o system that does reordering, block aggregation, > extents, .... than going to raw hardware. > > In RTL we do: > RT task passes request to Linux process: either waits or does not > Linux process does i/o > done > > I can trivially implement an "I/O daemon" that will make this transparent, if there is a need.
I'm certainly interested in this, and I have a few ideas here. Most importantly, what I want is efficient read/write of multiple files "simultaneously" (needs HUGE buffers), and a mechanism for telling the read-ahead what to do.
Reading files backwards is also useful... (Means that the read-ahead system needs to be aware of that kind of tricks. BTW, I'm not suggesting reversing on the data level! I'm thinking buffers; size set when opening would do.)
I'd be interested in helping with design and hacking, as I'll need the stuff sooner or later anyway. What I want from a multi-file streaming system is relieveing the application developer of the complex task of figuring out how to handle mutiple streams from disk without stressing the disk to death. Big issue in audio recording; might be useful for heavy data aquisition as well...
> > possibly shared memory stuff > > On the way. Next week probably.
//David
- 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/
| |