I think you're missing the fact that mmap() does not actually load the file into ram, but just provides a memory-like interface to the file. Likewise, if you are using read(), you are already taking advantage of buffering by the filesystem, so chunks of the file will be in main memory already. Performance is all the same at the bottom layer (blocksizes withstanding). At the bottom layer in the OS, it's half a dozen of one or 6 of the other 
As for documenting the low layer framework.. it is frightening stuff and is still churning regularly. The headers alone are over 600,000 lines of code and the complete multimedia codebase is somewhere on the order of 3 million. Aside from churning regularly, there are enough special use cases and gotchas that unless you sit next to the guys who wrote all of the plugins, filters, streamers, writers, readers, etc., it can sometimes be challenging to implement a graph and get it right on the first attempt.
We realize that there is a gap between the easy-to-use-but-less-flexible mm-renderer interface and the difficult-to-use-but-very-flexible low layer framework. We do intend to provide something which alleviates the difficulty factor of the latter. It just can't be promised for launch.
All that being said.. if you do want to stream files straight out of memory, I am told you may be able to use a pipe. The caveat being that we have not tested this thoroughly and that if you ever let the pipe run out of data, playback will error out and terminate (eg. make sure to keep the pipe fed!). At this point though, you may as well be using a file on the filesystem.
Cheers,
Sean
>I think you're missing the fact that mmap() does not actually load the file into ram, but just provides >a memory-like interface to the file. Likewise, if you are using read(), you are already taking >advantage of buffering by the filesystem, so chunks of the file will be in main memory already.
In our pak file we have thousands of files, it's several hundreds of megabytes.
Are you telling me that it is more efficient for me to load these files over and over again when the user is playing the game? You do understand that by mapping my pak file, I am insuring that my memory does not get fragmented, every time I load a file?
Yes, using fread/fopen in a hello world program that prints out text that is a file (given that the size is smaller than the page size) is more efficient than memory mapping it. But otherwise, probably not.
You have to count in that, whenever I tell the os or whatever os specific framework I'm using to play the same audio track again, it's highly likely that it is already paged in by the os. In these circumstances, there are some obvious advantages to using memory mapped files.
Not to mention doing 0 syscalls whenever I have to load small files. Which is very, very often.
Your code size seems very large, and I'm not saying that you should expose everything....just support for ptr as input and size.
Pipe is an idea, but seeing as I've inserted a special case for blackberry 10 already, there is no need to change anything . Game runs on much more limited hardware than the alpha device has, and runs great on bb10 so I'm happy .
Johan
