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.
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…
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?
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.
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.
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.