I’m trying to get my head around these createSound options and how they might work with what we do. Can someone lay out what exactly occurs when you combine the two options in the title: Is the memory you give treated as the entire file and it’s streamed from there to the memory Fmod uses? What kind of situations might that be useful in, memory that you can’t directly play sounds from? Anything else?
Is it then not possible to combine FMOD_CREATESTREAM and FMOD_OPENMEMORY_POINT or does it still stream it and point to different parts of the memory as it goes?
I’m thinking that I’m actually interested in the FMOD_OPENUSER option, is this the only/main way that you would go about creating a stream where non-Fmod code is in complete control of retrieving data from a file/some other storage medium? I know about the file open, read etc. callbacks but I wanted to investigate what else exists, specially for only loading specific types of files etc.
- identitycrisisuk asked 12 years ago
Im not sure what you’re actually trying to achieve.
FMOD_OPENMEMORY is for people who want to play a sound from memory instead of file.
FMOD_OPENMEMORY_POINT and the stream flag doesnt make sense. A stream copies data from the source into a circular buffer. This means pointing is useless because of the copy. It is already documented for what types of sound it can be used for. It can only be used for specific circumstances. Check FMOD_MODE documentation.
Yes you can override fmod’s file system with setFileSystem, or stream pcm data into a user stream, but they are totally different things.
Not so much trying to achieve something directly, just trying to get a bit more information on how things worked. Sometimes just writing down what you’re thinking makes it clearer. I was confused over whether opening memory and using it as a stream would treat that memory as the buffer for that stream rather than the full data until I found out about overriding the file system or setting pcm user stream callbacks.
I think overriding the file system is definately what we want to do, it’s just that the code written already was specific to events and soundbanks as that’s all we’ve used so far. That’s why I was looking to see if there was another way of streaming in data that would bypass those file read callbacks. But we need to make sure that it will work properly for loading anything and that will either be my or tech departments job, not to do with Fmod code so much
[quote="identitycrisisuk":3uikkknj]That’s why I was looking to see if there was another way of streaming in data that would bypass those file read callbacks. [/quote:3uikkknj]
I’m going to make a guess.. what you need can be achieved with specifying callbacks in a FMOD_CREATESOUNDEXINFO structure when you open the sound. This way it will only affect that sound and you can keep the other code as it was. Note that these callbacks will be called from other threads than the System update thread, so make sure any structures you modify from the callbacks are thread safe.
Maybe you want to have a look at the usercreatedsound example.
This uses the pcmreadcallback to create a sound on the run.
You also have the option of setFileSystem with callbacks or the similar FMOD_CREATESOUNDEXINFO useropen/read/seek/close callbacks.
At least I managed to get the filecallbacks example to work as usual after replacing the setFileSystem call with the createsoundexinfo parameter to CreateStream.
Yeah, I’ve had a look at that create sound example now, the data you’re creating there would have to be the full uncompressed sound data that you want to play right? So unless you have one simple file format it’d not actually be that useful for playing sounds from files.
The only reason I was looking at this is because there’s already code written here for the file callbacks and I wasn’t sure if it was compatible with the Fmod Ex API as I think it had the event system in mind more when it was written. Still investigating…
Please login first to submit.