I have 2 FSB files: one for dialogue that is localised; and one for music (that is not).
If I set them both to have 2 streams max, I would expect that the memory usage for each FSB would be the same. (The StreamingBufferSize is set only once at initialisation time).
Has anyone experienced anything that may cause one FSB to allocate its memory twice, for example?
- mattconnolly asked 8 years ago
Audiodev – thanks. Good to know that createStream ignores the maxStreams setting.
I’ve read your best practices (many times) but unfortunately on this project we don’t have the resources to implement them all, so I’ve got to make do with what I can.
We actually have 2 programmer selected events, so createStream is being called twice.
However, the real problem for me is the memory usage. No matter what I set the max streams setting to, the streaming buffer usage is double what I set it to.
For example, in my dialogue/music FSBs, the memory usage is like so:
Number of Streams Dialogue.fsb Music.fsb
1 stream: Dialogue = 387k, Music = 196k
2 streams: Dialogue = 774k , Music = 393k
3 streams: Dialogue = 1161k, Music = 590k
I might expect that the memory usage for Dialogue would be whatever it is set to + 2 x bufferSize because createStream is called twice, but it appears to be always double.
I also have some events that are playing sounds out of the same FSB so that they can be controlled using Designer (category mixing, for example).
Ironic since dialogue is also mono and only uses half the bandwidth as stereo music.
This sounds suspiciously like you’ve run into the big headers issue. Unless you use FSBank to build your fsb using small headers (something Designer currently doesn’t do) then you’ll pay 80 bytes (if memory serves) per dialog line per stream. So if you have, say, 2000 lines in your dialog FSB, that’ll be 160KB of header memory every time you open a stream from that FSB. That likely accounts for what feels like way too much per-stream memory.
Am I on the right track? If so, it’s not so much work to have FSBank build your dialog FSB instead of Designer. You can even have Designer poop out an LST that you feed right into FSBank.
You mean you can do this:
- Build Fmod Designer project, outputting FEV, Dialogue.FSB and Dialogue.LST.
- Then take the LST into FSBank and rebuild the Dialogue.FSB with small headers?
Still, I would have thought that there would be memory allocated like so:
1 x buffer for first call to createStream
1 x buffer for second call to createStream
N x buffers for Designer API according to maxStream settings.
Totalling N + 2 buffers. But it always seems to be 2 x N buffers.
Note, that I have a mixture of programmer selected and designer events coming from that single FSB; would this be problematic?
I’ll try it out tonight….
Using FSBank Generator to build the Dialogue.FSB file works fine – all my event driven and programmer selected sounds work as expected.
The memory savings are as follows: (Fmod Designer -> FSBank)
1 stream: 387kB -> 279 kB (saving 108kB)
2 streams: 774kB -> 559 kB (saving 215kB ~ 2 x 108)
3 streams: 1161kB -> 838kB (saving 323kB ~ 3 x 108)
There’s not a huge about of header overhead. There’s only a meer 1425 dialogue lines, I know others here are way more than that.
Whatever information is saved by using the small headers must be loaded once for each streaming buffer that is set in Fmod Designer. Seems a bit wasteful.
I’m beginning to feel like I’m barking up the wrong tree – or barking mad – I’ve changed the name of the FSB so that the programmer selected system won’t find it, forcing createStream to fail. Memory usage shows exactly the same!!! So, createStream memory usage must be stored somewhere else? Or at least not accounted for under the FSB’s memory usage…
Now it must just be that even with small headers on, there’s a lot of information being duplicated – once per stream in the "Max Streams" setting. It’s probably coincidence in my case that the amount of duplicated space is approximately the same as the size of the streaming buffer, leading me to the 2 x N assumption above, where really it’s 1 x N streaming buffers + 1 x N header data.
Enough time spent on this… the small header’s does save me something, and every bit counts. (Thanks again!)
Something seems suspicious here. I would definitely expect to see "N + 2" buffers worth of data. One thing is that FMOD won’t allocate it’s streams until you actually play N Events that refer to that FSB. Also, if your programmers are calling freeEventData when streams finish (which we do), you’ll only see the peak usage when all N streams are active.
In terms of actual memory usage, you’re right that paying for a full set of headers per stream feels super wasteful. That’s actually one of the reasons we switched to the LRU scheme. One more thing you can do to squeeze memry is make sure your programmers are calling createStream with the right flags like FMOD_LOWMEM. You can shave some additional memories that way.
As for the behavior you’re seeing after renaming and whatnot, that doesn’t make any sense at all. Something is very suspicious here. If you have the time, you should definitely dig into it more. My experience is that when stuff like this doesn’t add up, it’s an bug or memory savings wating to be discovered.
Ok, so I’ve just learned that it’s probably because of our "programmer selected" voice system.
Is there any way to program a programmer selected system to use streams within the limit allocated by the FSB? Or are they always separate?
When you use "programmer selected" sounds, your Max Streams setting is ignored. It’s up to the programmer to create the right number of streams (one for each call to createStream on your voice FSB).
Also, it may not apply but check out my Voice Best Practices thread for some thoughts on a different (and potentially slightly better) way to handle voice w/ FMOD.
Please login first to submit.