Messages in this thread | | | Date | Fri, 23 Jul 1999 21:31:30 +0200 | From | David Olofson <> | Subject | Re: real-time threaded IO with low latency (audio) |
| |
yodaiken@chelm.cs.nmt.edu wrote: (...) > > This is what I mean by latency not being a problem. The difficulty > > arises as soon the system is no longer quiescent: the kernel starts > > Everything is easy when the system is not doing anything.
...while I intend to stress the disk I/O A LOT with Audiality's hard disk recording daemon. Kind of pointless trying to avoid loading the rest of the system, as hard disk recording is the main reason why I started this project.
(...) > Linux is not losing time locking/unlocking, it loses response time by not > preempting tasks in kernel mode. But preempting tasks in kernel mode would > be a terrible design choice for a general purpose OS and it a terrible pain in the > ass to maintain.
Agree. While being an uggly hack, it's also quite pointless wasting cycles on allowing this kind of real time, while most of the system doesn't need it. Finer grained locking for improved soft real time and overall performance is nice, but hard RT should be kept a separate service, IMO. Easier integration with the non(/soft) real time system would be nice, though...
BTW, while hacking the es1370 driver for RTL, I've got a set of Linux<->RTL interfacing functions together. The driver is currently (while I'm typing this, actually) running on an RTL interrupt, while still looking exactly like the original driver to applications. I didn't touch much of the driver code itself to do this; just some minor adjustments in order to get the waitqueues under control, so that the RTL interrupt can wake them up. (Looks a lot like the RT-FIFO code.)
I'll move those functions into a separate module and perhaps clean up the interface a little. Anyone interested? Ideas?
So far, this driver hack turned out to be simpler than I expected. :-) I'm not sure all drivers are that friendly, though...
Next project: interruptible_sleep_on() for RTL tasks, so that I can open and use the driver directly from RTL, bypassing the file system, while keeping 95% of the original driver code.
> BTW: I have never seen any serious performance numbers on BEOS. Do you have a source?
Would like to see those figures too. All I managed to find out (didn't try all that hard, and I haven't got BeOS) is that they managed to achieve 3 ms audio latency, but I know nothing about reliability, how it was done, etc.
//David
PS. Thanks for filling me in on the real time stuff! :-)
- 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/
| |