I wasn’t saying FMOD must have such runtime options.
Because I’m still learning about FMOD API, I thought there could be some other ways to achieve it, and my approach above was wrong. (That’s the reason why I said DIRTY. I never thought it was the right one.)
I’m currently working on a test project to see if FMOD API is the way to go.
As for the sample rate, yes, it’s not that problem most of the time including my current test app.
But about the buffer size, I’ll be very happy if it could be changed even after initialization, to be honest.
My app offers virtual instruments with high-quality audio samples, so I have a plan to provide an adjustable buffer size option for users.
While some users may choose the best quality over latency, others may choose the lowest latency (even with stuttering) over quality.
In any case, users need to test several times themselves.
But the user experience with my app will be bad because they have to wait until all the big-sized audio samples are off-loaded and reloaded again every time they change the buffer setting to see if it’s better or not.
The release version will be a lot worse after the encryption is added to protect audio sample data files.