Messages in this thread | | | Date | Mon, 10 Jul 2000 00:28:21 +0000 | From | Andrew Morton <> | Subject | Re: [linux-audio-dev] lowish-latency patch and toolchain |
| |
Tom Pincince wrote: > > I feel that pro quality audio on regular Linux is achievable, combined > with some non-radical optimizations and common sense. I've been doing > it for years on mac and windows. The way we accomplish this is by > dedicating the box to audio, disabling all non-essensial background > tasks, and generally avoiding anything that might cause the OS to become > too busy while we are actually recording.
If you do this with 2.4+my patch you'll get sub-2-millisec latency for the rest of your life.
> ... > When Juhana raises the issue of deleting large files as being too > important to qualify as a DDT, I find this to be misleading.
Sorry, it was bogus. You can delete a 100 meg file and latency doesn't go above 300 usecs. The problem was with returning a huge number of pages to the kernel - munmap(), exit() and madvise(MADV_DONTNEED). It chews 1 millisec per 1000 pages. This has been fixed, but I'm still seeing a 4 millisec bump when you do:
malloc(100 megs) play_with_it() exit()
This is probably not worth fixing.
> While it > is true that audio apps generate lots of large temporary files that must > be deleted, it is not true that file deletion and recording must happen > simultaniously.
Yes, I need to do a streaming-to-huge-file test. If this makes kswapd wake up we lose. Big time.
kswapd can't/shouldn't be fixed with reschedule points. I suspect there are fundamental algorithmic problems. Its job is, basically, to write stuff on the disk. I'll admit that my knowledge of Linux VM could be written on a very small napkin with a very large paint roller, but I can't see why kswapd should chew 30,000,000 cycles without blocking on I/O. We'll see...
- 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/
| |