One of our programmers approached me with a problem that priorities and weights alone cannot solve: you can limit the number of sound channels per Sound Definition, but not per Event, nor per Category. At least not in FMOD Designer.
Actually I don’t know if the channel limit in a single Sound Definition applies within one event only, or all instances of that event, because I cannot play multiple events simultaneously within FMOD Designer / Event Player. Does it? If I limit a Sound Definition’s channels to 3 and play multiple Events that contain that sound, do they reserve 3 channels [b:3hp3v8j3]each[/b:3hp3v8j3], or 3 [b:3hp3v8j3]in total[/b:3hp3v8j3]?
This may sometimes introduce a problem. Imagine (an extreme example) you have 100 AI guys running and shooting around the player, roughly at the same distance (so you cannot priorize by distance). You want to hear their footsteps, but not ALL of them because they would quickly flood all the available audio channels. And you need to hear their gunshots too. Gunshots are louder so they can have a higher Priority, but you don’t want the gunshots to silence the footsteps completely, either. The ideal situation would be, like, 3 channels [b:3hp3v8j3]in total[/b:3hp3v8j3] reserved for gunshots and 4 for footsteps. This way you could hear both the footsteps and the gunshots without flooding the channels. They would be densely triggered so there would be a lot of channel stealing, but you would hear all the sounds.
But how should limiting like this be done? Could / should Categories have their own master virtual channel limits?
[quote="brett":200petro]max playbacks is the maximum number of that event you want to hear , ever. So this is a global limit in the game for that event.[/quote:200petro]
Ah! Okay, that solves a lot. I had missed that parameter.
[quote:200petro]Is the other problem that you then want to limit the number of gunshots for 1 player? (ie so that they dont have 7 overlapping gunshots for the player?). That maybe something the programmer has to do, because we cant tell if you’re triggering an event from the same guy or multiple different guys.[/quote:200petro]
I suppose this is easiest solved by creating separate gunshot events for the player and the enemies with different playback limits.
Thanks for your tips!
[quote="brett":h1yg4kcg]That maybe something the programmer has to do, because we cant tell if you’re triggering an event from the same guy or multiple different guys.[/quote:h1yg4kcg]
Another problem showed up. We’re doing the limiting by weapon, not by guy. There would need to be higher level limiting than Event Max Playbacks, because if you have 100 AI guys with 7 different weapons running around, you get 7 times the channels allocated.
Would it be possible / plausible to implement higher level playback limiting to FMOD Designer, for example limiting max playbacks per category?
[quote="brett":szyacwwz]No you don’t because you just set the max playbacks for the weapon to a low number? Setting a weapon to maxplaybacks = 5 means you only play it 5 times, period. I thought you already understood that because it is global.[/quote:szyacwwz]
I already understood that it’s global, but the problem is, the sound of an AK47 and the sound of a Shotgun are [i:szyacwwz]separate[/i:szyacwwz] Events. If they both have a MaxPlaybacks limit of 5, and you have a bunch of AI guys firing AK47s and shotguns at you, they will allocate 5+5=10 channels in total.
However, if there was a category “gunshots”, which contains both the AK47 and Shotgun and has a MaxPlaybacks of 5, any and all guns would allocate only 5 channels in total at any time, allowing room for other sound types too (like footsteps).
There needs to be a higher level limit for channels / events. But I guess it can be implemented into the game code outside FMOD as well, if needed. We did that in Max Payne 2 by assigning each sound an ID number. Any sounds that shared the same ID number shared a common total channel limit. It helped to keep the channel usage manageable and made channel stealing work better because each sound type only stole channels from their own kin. You never heard a footstep interrupt a gunshot.
[quote="brett":pmz2dko6]that ‘id’ is just the same as fmod priority, which is in the event properties. If weapons were a higher priority than footsteps, you would never hear a footstep interrupt a gunshot either.[/quote:pmz2dko6]
Priority is slightly different from ID, because all the sounds compete with each other on only one axis of priority – higher priority sounds override lower priority ones, regardless of the type of sound.
IDs (or category-specific MaxPlaybacks) allow finer control over the way sounds are prioritized, since there are multiple “slots” for each type of sound. This way sounds that should not interfere with each other will not, as the different types of sounds only compete within their own category. As an example; with a simple priority system a loud gunshot would override a looping ambient rain sound – which wouldn’t sound very good. If ambience and gunshots have their own categories, they will never interfere with each other, yet thanks to the channel limitation neither will use an excessive number of channels.
BTW, what happens when a sound is overridden by a higher priority sound, or a channel limit is met? Does the lower priority Event get immediately interrupted? In XACT you could specify a rule what happens in such a situation. The options were “Fail to play”, “Queue”, “Replace oldest” and “Replace quietest”.
BTW, is there any display in FMOD Designer / Event Player to see how many channels are playing in total?
Or is it so that only the CPU usage matters, since the virtual channels are handled automatically?
I asked our technical director about the Xbox360 audio hardware; turns out there is basically none; that all audio mixing, effects and playback are done thru the CPU. If this is the case, then indeed the number of channels matters less than the amount of CPU used.
A quote from the Xbox360 audio specs:
[quote:3rkx1fo6][list:3rkx1fo6][:3rkx1fo6]Multi-channel surround-sound output [/:m:3rkx1fo6]
[:3rkx1fo6]Supports 48-KHz 16-bit audio [/:m:3rkx1fo6]
[:3rkx1fo6]320 independent decompression channels [/:m:3rkx1fo6]
[:3rkx1fo6]32-bit audio processing [/:m:3rkx1fo6]
[:3rkx1fo6]More than 256 audio channels[/:m:3rkx1fo6][/list:u:3rkx1fo6]The Xbox 360 has multi-channel surround sound that supports 256 channels of 48 KHz, 16-bit digital audio. The 32-bit audio processing is handled by the CPU.[/quote:3rkx1fo6]
So at least in our case a channel counter is not an absolute must.
I’d been thinking about this for a current problem, but there doesn’t seem to be any way to do this with FMOD that I can see. A rough example is that in a racing game, there could be up to 10 unique cars per race, but equally they might all be the same car. I only want to hear a maximum of 4 car sounds at any time though. The real problem is that the sounds are looped rather than single shot, so the events aren’t released automatically by the sound ending.
It doesn’t seem to make sense to allocate a max playbacks of 10 per car since that’s wasteful and could allocate for 100 events if 10 different cars were picked (even though only 10 are needed, and only 4 need to be played).
If the max playbacks was set to 4, I would have to manually stop/start events (with a getEvent) to get new instances since at the race start some cars wouldn’t have events, and this would change during the race. This would need some form of controlling code (e.g. stopping the furthest/quietest cars), which means that the "Max playbacks behaviour" becomes useless, and I would still need to calculate what that would have done anyway. This still doesn’t solve the problem of requiring 4 playbacks per car when really it’s just 4 playbacks for ALL cars that I need though.
So is there a better solution than having to do all this manually? I thought about using the callbacks rather than having custom game-side code for neatness (albeit more complex), but I’d still have the 4 instances per car limitation.
- crouton answered 10 years ago
Please login first to submit.