On Fri, Jul 14, 2006 at 12:06:23 +0100, james(a)dis-dot-dat.net wrote:
On Thu, 13 Jul, 2006 at 04:45PM -0400, Stephen
Sinclair spake thus:
A thought occured to me recently...
If I am writing an application which needs to stream a large wav file,
I am having to write something which reserves some memory, and loads
pieces of the wav file from disk on request. Say I need to be able to
jump around the file a bit, I would have to detect when the piece is
not available and load it in as appropriate.
... which I realized is exactly what the OS VM paging system does.
So, has anyone tried using memory-mapped files for streaming audio
data? (obviously, I mean, in a non-realtime thread, using a buffer).
Or would this be totally inefficient?
I was thinking it could really simplify programming, just directly
accessing parts of the wav file as needed, and letting the OS load it
up into physical memory when it wants to.
It's perfectly sensible. I do it a lot, because it's easy. The
problem is having to load the whole thing into memory before you
start, which makes things alow to start. If you're playing linearly,
to solve this, you need can load it in chunks and start playing the
first chunk straight away.
mmap-ing doesn't epxlicitly load the whole file, just bits as you
request them. I wrote an app on linux that accesses large files (1-4 GB)
this way recently, and the performance was certainly no worse than
buffered read()s.
It is very convienient, but there are some gotchas, especailly on 32bit
machines where you will run out of address space really quickly. Also, my
feeling is that linux is a bit conservative about how much ram it will use
to map the file, though there is a hinting mechanism you can use to say
what you want that mmaped region for. It's madvise(2) on Linux and BSD.
I'd second what Erik said though, for audio file i/o, use a library. The
ammount of i/o is really tiny, so overoptimising it is silly.
- Steve