Because we need to set them all before calling FMOD_System_Init(), it seems impossible to change them ever again after initialization. But as you know, there are tones of music applications which offers options to adjust them freely.
One way I can think of is to release and initialize again every time a user changes those settings, but it seems too dirty.
Does FMOD API offer a cleaner and nicer way to do this?
There is no way to change the System sample rate nor buffer size once System::init has been called. To do so you must shutdown everything and start up again. Usually an appropriate rate and buffer size (often left at default) is chosen at design time and remains in effect, why do you need to change these things at runtime?
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.
Thanks for the added information, I understand what you’re doing now. Unfortunately many parts of FMOD perform initialization based on the chosen buffer sizes, for example DSP effects will preallocate buffers for the expected DSP block size. It’s for this reason there is no way to change the buffer size without shutting down FMOD and starting up again.
In fact, we have this exact setting in FMOD Studio, when changed we do exactly that, we shutdown the audio system and rebuild it again. It may be slow, but for each user it’s only ever changed a couple of times to get the desired latency then never touched again so it’s not largely inconvenient.
Thanks, I understand and actually I’m not complaining haha.
I love FMOD so much that I reported several bugs in the past and your team fixed all of them.
FMOD was already great but it keeps getting better and better 
Just to clarify, all the FMOD_SOUNDs need to be reloaded after restarting the system, right?
Thanks for the kind words
Yes, you will need to release all sounds then release the FMOD::System