0
0

I’ve recently been going back over how we’re using the existing FMOD 3.7x API to see how best to switch over to FMOD Ex now that we need virtual channels going forward. I’ve got some questions about the how I should proceed.

Virtualizing channels looks to be a great addition since I can now just start up any looping environment sounds when the emitters come within loading distance of the player and don’t have to do anything until it moves out of range. Previously I was having to loop over them and using my own distance checks assign or unassign them to channels and try to get the positions right to keep the player from noticing, but it never really worked too well (lag on jumping into the stream).

My first question is if this is the proper way to do this? Currently all sounds are streamed and never loaded since I’ve got just under a 400MB of sound files. I’m assuming these virtualized streaming channels won’t be hitting the harddrive? And how much latency should I expect when they do become non-virtual?

Another issue is I’ve got some channels which must not be reassigned. It looks like the SetPriority and SetWeight are what I need to deal with it, but how are they used? I didn’t see anything in the documentation about what values do what.

Also, is ducking going to make it in, or do I need to loop through all the other channels and set the volumes during voiceovers? If so, should I manually ramp down and up the other channels, and which should this be done on all the virtual channels, or just the “real” ones? (How do you check if a channel is virtualized, btw?).

Finally, I could really use the start delay in the original feature list, but would be even better if I could have a sound start at a specific time. Also, the stitching would be handy, but I didn’t see it in the current version. Is it still planned?

Our music is made up of 3 tracks played on 3 channels which is divided in 8 bar sections (about 22 seconds). Every 8 bars I start 3 new sounds with varying relative volumes and the time needs to be seamless. I do this right now by starting the streams a little early but it isn’t very accurate. Complicating it is some sections play beyond the 22 seconds to complete the sustain/decay of notes at the end, sometimes requiring an additional channel to be assigned to overlap with the start of the new section. It would be great if I could queue up these next sections to start exactly on the bar, having FMOD do the prebuffering during the currently playing sections, then I can clean up the channels after the sections finish without worrying about the timing.

Is there a better way I should be doing all this?

  • You must to post comments
0
0

[quote:1ffbwcga]I think an audible latency would be the best way to do it, because most sounds swap in at the furthest distance out of all the currently audible sounds, where the volume is just about 0 anyway.

I havent put in a non flushing seek option but i can do this if you like.

[/quote:1ffbwcga]

Yes, I believe this would work fine; I don’t want to see CPU spikes and can live with a delay on just swapped in channels as long as you have something in your channel picking algorithm to keep it from ping-ponging on/off (range threshold).

[quote:1ffbwcga]Priority is what you would think it is, ie it makes each channel more important than the other, selectable by the user. [/quote:1ffbwcga]

So a higher value is more important, with it keeping as real the N channels with the highest priority scaled by audibility scaled by weight? Sounds reasonable.

[quote:1ffbwcga]Yes ducking should make it in, but right now you can use FMOD_CHANNEL_ALL with setvolume then set the volume for your voice over.
[/quote:1ffbwcga]

Hmm.. do I handle FMOD_CHANNEL_ALL by:

[code:1ffbwcga]
FMOD_SYSTEM *fm_sys;
FMOD_SOUND *fm_sound_vo;
FMOD_CHANNEL *fm_chan_all;
FMOD_CHANNEL *fm_chan_vo;
...

fm_sys->createSound("voiceover.wav",FMOD_CREATESTREAM | FMOD_HARDWARE,&fm_sound_vo);
fm_sys->playSound(FMOD_CHANNEL_FREE,fm_sound_vo,TRUE,&fm_chan_vo);

fm_sys->getChannel(FMOD_CHANNEL_ALL,&fm_chan_all);
fm_chan_all->setVolume(512); // half volume
fm_chan_vo->setVolume(1024); // full volume
fm_chan_vo->setPaused(FALSE);
[/code:1ffbwcga]

If I want to ramp down the other channels, then ramp back, can I do the setVolume to FMOD_CHANNEL_ALL immediately followed by setting the voiceover channel back to full without any anomalies (ie. voiceover dropping in volume then popping back to full)?

[quote:1ffbwcga]The stitching stuff still has to be looked at, it could possibly be like fmod3’s stitching, which has restrictions (ie the queue has to be defined before playback), or maybe not, i can’t say right now.[/quote:1ffbwcga]

I generate the queue dynamically so that wouldn’t work too well… I want to assign the next sound to play on the channel while another is playing, but if I could have a sound start on a channel at a specific time (or delay I can calculate from current time) I can get the same effect.

Automatic volume ramping (enveloping) would really be nice, too ๐Ÿ˜‰

  • You must to post comments
0
0

[quote:bs1vcuas]FMOD_CHANNEL_ALL means all the channels. If you set volume full on all channels, then it will set everything to full including the voice over (which was already full anyway so it wouldnt matter)
[/quote:bs1vcuas]

I don’t think you understood my questions. I was asking how to specify FMOD_CHANNEL_ALL in the new API since it uses classes instead of indices. Does System::getChannel(FMOD_CHANNEL_ALL,..) do the same job?

The second part of the question was if I could do the volume ramping by applying the new volume to FMOD_CHANNEL_ALL and setting the voiceover channel immediately back to full volume without having problems with that channel also going lower:

[code:bs1vcuas]
int volume = 1024;

while (volume >= 512) {
fm_chan_all->setVolume(volume);
fm_chan_vo->setVolume(1024);
volume–;
.. delay ..
}
.. wait some more ..
while (volume <= 1024) {
fm_chan_all->setVolume(volume);
fm_chan_vo->setVolume(1024);
volume++;
.. delay ..
}
[/code:bs1vcuas]

to ramp down all channels but the voiceover, then ramp them back up as voiceover ends. Or do I need to loop through all the channels except the voiceover channel doing the setVolume to keep it from messing up the voiceover playback volume?

Actually, I probably will have to do them individually since they may not all be at full volume so I’ll need to scale each channel’s volume separately.

[quote:bs1vcuas]You cant insert a sound into a queue and expect to have it happen immediately. FMOD may have buffered the stream 1000ms ahead of time and already processed stuff that you havent heard yet. This is why fmod doesnt allow dynamic insertion. If you didnt mind the 1000ms latency dictated by the stream buffersize then i guess you could tag it on the end but it might not make sense or be useful to many people.[/quote:bs1vcuas]

I don’t expect it immediately; I’ve got 20 seconds or so before it needs to start.. I just need to make sure the start time is accurate. I decide the next section to play while the current one is playing and just want to queue it to start at the end of the current section with at least 20 seconds before needed.

  • You must to post comments
0
0

[quote:ep7erk52]You should probably just call setMasterVolume and use setVolumeAbsolute for the voice over. That scales volumes, and also ignores channels set with the absolute function.

[/quote:ep7erk52]

Excellent. That will do exactly what I want; lower everything but the voiceover in one call by a relative amount.

[quote:ep7erk52]As I said it hasn’t been done yet but i expect it wont be hard to do what you want. It’s possible we could use a stream clock that allows sounds to be inserted at precise offsets using setstarttime/setdelay type functions or allow dynamic stitching with some helper functions to avoid buffering issues.[/quote:ep7erk52]

Sounds like it will do what I need, then. I just wanted to make sure I could start a stream paused, but have it start buffering so at a specific time it could start playing without the latency of the prep work.

Another question I have is about the software mixing. If I specify FMOD_SOFTWARE | FMOD_2D, will it mix all software channels and stream to one “real” hardware channel, while all FMOD_HARDWARE streams use the hardware mixer? I’m trying to make sure I don’t steal too many limited hardware channels for the music. Right now I can have a worst case of 4 tracks + those 4 overlapped during previous section sustain/decay, times 2 while crossfading for a total of 16 channels just for the music ๐Ÿ˜ฎ … if they’re all software mixed it shouldn’t be a problem. Does the virtualizing/priority take that into account?

Is there a whitepaper or similar with details on how games typically use FMOD? A lot of questions could be answered by having a case study to read ๐Ÿ˜‰ .

Anyway, thank you for taking the time to answer my questions.

  • You must to post comments
Showing 3 results
Your Answer

Please first to submit.