>> 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.
This would be true for straight-forward end-to-end sample
playback. However, in the case of an HDR system, there is some benefit
from having a significant chunk of recently read and soon-to-be-read
material in RAM. A typical operation is to stop the transport and then
skip back some distance. If we seek back by less than amount in the
cache (and on a typical audio machine, thats going to be at least
100MB), we end up not having to do any disk I/O at all. Big win for
"instant access". My studio system has 256MB of RAM. Assume half of
that for the buffer cache, and 24 tracks of 32bit/48kHz data, and
thats 28 seconds of material per track. I would agree that its not an
incredibly useful duration - most locates of the transport "mechanism"
will be longer than that - but even so, its easy to imagine situations
in which its a win.
The issue is whether the behaviour of the system buffer cache is close
enough to what userspace would do if it was forced to or chose to
implement this buffering on its own.
I don't understand the Linux buffer cache well enough to know if this
is true. I suspect that it isn't.
--p
-
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