Minor silly questions

FMOD Engine
1

I know I should post each question separately with a proper title for others here, but below are mostly very minor and silly questions from me, so please bear with me.

  1. Is it okay just to replace the newer libfmod.so / fmod.dll with the old one and not recompile my application again with it, if the signatures of all the functions I’m accessing are still the same?
    I thought it’s one of the reasons dynamic libraries exist and actually worked well so far this way, but some guy recently told me that I needed to recompile, and even my GIT (not always but sometimes) thought my application’s binary data changed after recompiling.
    So I’m confused now…

  2. Why is FMOD’s default DSP buffer size on Android 512 rather than 256? Is it because there are still many Android devices that don’t support FEATURE_AUDIO_PRO or FEATURE_AUDIO_LOW_LATENCY? Or is it a just-in-case safe margin value for FMOD users that would add many DSPs? What if my application only uses one or two global channel-group reverbs and a few EQs, and targets recent devices with FEATURE_AUDIO_PRO or FEATURE_AUDIO_LOW_LATENCY, and low-latency is very important? Do you still recommend sticking with 512 over 256?

  3. Can I implement an Audio Export feature with the FMOD API? I mean like professional audio apps, without playing any sound and with a faster process time.

  4. I wonder what FMOD_Channel_SetPosition(soundChannel, newPosition, FMOD_TIMEUNIT_MS)'s expected behavior would be when the newPosition is greater than FMOD_Sound_GetLength()'s return value.
    In my simple tests, it just moved to 0.

  5. After a sound stops (either by itself or FMOD_Channel_Stop()), can I still properly check the state of that sound using FMOD_Channel_GetPaused() and FMOD_Channel_IsPlaying() anytime?
    I don’t still understand how the virtual channel system exactly works. If channels are reused, I think checking the old FMOD_CHANNEL variables may return the states of new sounds rather than old ones, at some point (after playing many sounds for many hours).

Sorry for spamming questions.

Thanks!

2

  1. Yes you can just replace the dynamic library with a newer one provided it’s from the same major version. So if the game is built with 2.01.00 you could swap in the dynamic library from 2.01.05 without problems. Just don’t swap in the dynamic library from 2.02.00 for instance.

  2. Android audio is a terrible place, with hundreds of different devices, each with their own buffering characteristics. We highly recommend you leave the buffer size at 512 for maximum compatibility. If you can ensure you are running on a subset of known good devices then you may consider 256.

  3. You can set the output via System::setOutput, if you use FMOD_OUTPUTTYPE_WAVWRITER_NRT (note the NRT stands for non-realtime) you can output audio to a .wav as fast as you call System::update.

  4. Id expect a return of FMOD_ERR_INVALID_POSITION from setPosition.

  5. No, once a Channel stops the handle will go invalid, you will received FMOD_ERR_INVALID_HANDLE. Virtual voices limits how many sounds are audible, you can still use the Channel handle for a virtual voice. If you don’t have enough Channel handles (set via System::init) they can be reused, if you attempt to use a stale handle you will get an error FMOD_ERR_CHANNEL_STOLEN, so you don’t have to worry about getting the new sound state.

1 Like
3

Thank you very much!

Now all my confusion cleared, except for the last one…
Are you talking about both FMOD_Channel_GetPaused() and FMOD_Channel_IsPlaying() or just the FMOD_Channel_GetPaused()?

If it applies to FMOD_Channel_IsPlaying() too, I don’t get why the function exists in the first place.
According to you, the function will only work when playing, and it will return either FMOD_ERR_INVALID_HANDLE or FMOD_ERR_CHANNEL_STOLEN after stopped.

So you mean we can check if a specific sound stopped (either by itself or FMOD_Channel_Stop()) by getting a return value which is either FMOD_ERR_INVALID_HANDLE or FMOD_ERR_CHANNEL_STOLEN?

4

Channel::isPlaying is slightly more accurate since there is a small window in time between when a sound stop playing naturally (at the end) and the Channel object is invalidated. The best approach when using Channel::isPlaying is to ignore any error codes returned and just rely on the isPlaying boolean returned. Even if there is an error isPlaying will be accurate.

1 Like
5

Great!

So you mean even after calling FMOD_Channel_Stop(), I can still rely on the boolean value of FMOD_Channel_IsPlaying() regardless of any error code returned by it?

Gosh, I was so worried if I had to modify all the logic in the past projects because I had been heavily relying on FMOD_Channel_IsPlaying() for everything.

I knew FMOD_Channel_Stop() does release all the resources, but I didn’t think much about the relationship with FMOD_Channel_IsPlaying() until recently.

Now I can confidently use the function.

Thank you!

6

Yes, that is safe. We set isplaying to false before we validate the channel handle, so even if it is invalid you can rely on isplaying.

1 Like