0
0

I’m using FMod to asyncronously open compressed audio samples. I’m loading the compressed audio data into a memory buffer though our internal file routines and handing this to FMod. I understand that FMod will use it’s own memory internally when using FMOD_OPENMEMORY eventually, but does FMod require access to my original memory buffer until it’s finished decoding (detected via a Sound’s getOpenState() call or a callback)?

  • You must to post comments
0
0

I guess I’ll go ahead and reply to my own message. Making a slight adjustment to my code to preserve the memory buffer until the sound open is completed has fixed the issue I was having. So, I’m assuming this is indeed the way this works. It makes sense, otherwise FMod would have to allocate an extra buffer per playback.

I’d recommend making a note of this behavior in the documentation though.

  • You must to post comments
0
0

define FMOD_OPENMEMORY 0x00000800 /* "name_or_data" will be interpreted as a pointer to memory instead of filename for creating sounds. Use FMOD_CREATESOUNDEXINFO to specify length. FMOD duplicates the memory into its own buffers. [b:oyj8nwcu]Can be freed after open.[/b:oyj8nwcu] */

It pretty much does, an if you’re using FMOD_NONBLOCKING then technically it hasnt opened until it says it has.

  • You must to post comments
Showing 2 results
Your Answer

Please first to submit.