0
0

I am currently evaluating FMOD and I’m not sure how to handle this situation.

I have over 10000 sounds I want to stream, with stitching (voice commentary). With our current system we have the streams in 4 banks, the biggest one has about 5000.

Originally I thought I would do the same with FMOD, creating fsb’s and using setSubSoundSentence() for stitching. Unfortunately I found that the memory usage for my 5000 stream fsb was about 600K (with small headers and FMOD_LOWMEM). If we want 2 streams at once that would be 1200K which is a lot for us to give to streaming.

One idea is to split up the banks even further, say 500 streams per fsb for example. Then I could stitch using a method similar to the realtimestitching example. Now as I write this I’m wondering if I should just stream each file individually, instead of in an fsb (or put each in their own fsb).

I would think there are other people with this many sounds, if anyone has some advice about this I would appreciate it.

thanks

  • You must to post comments
0
0

FSB headers are cached, so it wouldn’t be 1200kb it would be 600kb.
Smallheaders are 8 bytes per sound, so i’d be suprised if you were getting 60 bytes per sound as you are claiming. Actually i’m pretty sure this wouldnt be the case.
Besides the 8 bytes per sound, there is a 4 byte offset stored per sound, so it should be more like 120kb for 10,000 sounds.

  • You must to post comments
0
0

Ok, that’s not what I’m seeing, I’ll have to look into it more tomorrow I guess. I just tested it quickly in the playstream example and I got the same result. I changed the createStream call to use my fsb and added the FMOD_LOWMEM flag.

Before the call to createStream, Memory_GetStats returns 415288, afterwards it returns 1046626.

I also created another stream and you are correct, it does cache the data. I didn’t realize. Though it still jumped up to 1376204.

I used the sample bank generator to create my fsb, and I’ll mention that I’m testing on Wii right now if that makes a difference.

  • You must to post comments
0
0

The memory you are seeing is the stream buffer. That is adjusted with System::setStreamBufferSize. This adjust how much is read from the disk at a time.
FMOD::CREATESOUNDEXINFO::decodebuffersize is also used to decode into, from the disk buffer. This value controls that size.

Note that they are configurable for a reason. The smaller those values are the more suceptible they are to disk read times and therefore stuttering/skipping noise.

  • You must to post comments
0
0

I’m using the default stream buffer size which I believe is 16K, which means 32K per stream if I understand correctly.

I set up my own memory functions in the playstream sample so I could see where the memory goes. I’ve modified it to open my fsb (4911 subsounds) for streaming twice. The first time it allocates a 260KB chunk, 78 bytes for each subsound (4911*78 = 374KB), and some other misc allocs.

The second time I open the fsb stream, it skips the 260KB (I assume that’s the fsb header) but it still allocates the 78 bytes for each subsound.

Does that seem correct? It seems a lot bigger than your post suggested?

  • You must to post comments
0
0

If you’re on wii then every sound has an ADPCM context that it uses. I can’t remember the exact size but the context is a structure containing coefficient information. You can’t get around that on wii. We don’t cache that info though i think, we could probably do that.

  • You must to post comments
0
0

Ok, thank you very much. If I wanted to avoid allocating that much memory, could I leave them as individual files and still stitch them? I know this is how it’s done in the realtimestitching example but I want to make sure that it will be fast enough when reading off disc and that I will be able to use FMOD_NONBLOCKING.

  • You must to post comments
0
0

Its less efficient, but yes you should be able to do this. I’m not sure you can create a user GCADPCM sound though, we’ll check that.

  • You must to post comments
0
0

actually you can’t, because there is all that extra stuff like adpcm context structures etc that i mentioned that need to be supplied.

  • You must to post comments
0
0

I see. It seems like my best option then is to break up the streams into multiple banks, making sure the ones that need stitching are in the same banks, then opening/closing them as needed.

Unless you have any suggestions?

  • You must to post comments
Showing 9 results
Your Answer

Please first to submit.