Messages in this thread | | | Date | Sun, 25 Jul 1999 04:25:50 +0200 | From | David Olofson <> | Subject | Re: real-time threaded IO with low latency (audio) |
| |
Bill Huey wrote: (...) > Yeah, maybe I'm being completely naive in myunderstanding of buss > bandwidth sharing, but I refuse to accept the *above* given what > modern graphics hardware can do with AGP2 and disk controllers > with DMA.
So do I... This is a software problem. Just happens to be a rather tricky one to solve...
> How about a special optimization to the swap that allows for > high speed handling of linear page faults ?
Sounds like a very hard thing to get working efficiently... And very limited in usefullness. What if you're handling several stream? (Like multitrack audio :-) How would that be handled efficiently? If you just interleave the data, you'll end up with a useless structure on the disk, while the swap can hardly be expected to take care of you writing to several buffers at once.
> If I'm hardware lock/bandwidth stupid, then please correct me.
Nope, just keep working on the disk I/O performance tuning, and use normal file I/O, or possibly grab an entire partition and use a custom (huge block) file system if you really need to get close to the max transfer rate of the drive. IMHO, if this kind of solutions can't provide the performance you need, Linux' disk I/O is inefficient and must be fixed. And it would be in that case. Who has a problem with raw power? :-)
> > (currently working on a megapixel digital "video" system myself) > > I'm doing real time *non-so-critical* digital audio here. ;-)
Not-so-critical means? Usually, audio is a bigger problem than video when it comes to real time scheduling jitter. 60 Hz frame rate means 17 ms/frame, while most audio folks (don't count me; I'm a latency maniac ;-) want 5 ms processing latency. And off course, everyone wants to use 90% of the CPU power!
//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/
| |