Paul Barton-Davis wrote:
> Sure, but the weak link here is disk seeking, and there's no way to
> remove that from the system. If you don't interleave the data for each
> track (which is, I believe, untenable for HDR), you are required to
> seek between the files as you read ahead for each one. The overhead of
> kernel->user space copying is completely trivial compared to the seek
> time. So, as nice as the DMA-to-userspace approach sounds, I don't
> think it will actually help much in this case.
Oh, But it DOES!
Not because of the DMA-to-userspace, but because you're not poisonning
your disk-cache with HUGE files.
Caching stuff from a multimedia file doesn't really help: The file is
larger than RAM anyway, and to play it the first time you need to get
it from disk, and to play it a second time you better be able to read
it from disk again.
If you're doing multiple tracks, the chunks that you wrote them with
better be large enough that you can read large contiguous chunks on
playback. If you're doing 10 80kbytepersecond channels, You'd better
read more than 80k per read if your disk doesn't sustain more than 10
seeks per second.
If the OS gets smart on you and starts buffering stuff, things may
even go "out of control" for the application, which is not what we
want.
SGI has guaranteed access rate. This means that the OS needs to know
transferrate and seekspeed of the disk, so that it can allot buffers
and bandwidth on that disk. It isn't all that complicated to do.
Roger.
-- ** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * Common sense is the collection of * ****** prejudices acquired by age eighteen. -- Albert Einstein ********- 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 : Fri Apr 07 2000 - 21:00:08 EST