On Fri, Jul 14, 2006 at 12:06:23 +0100, [EMAIL PROTECTED] 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
