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/
This archive was generated by hypermail 2b29 : Sat Jul 15 2000 - 21:00:10 EST