Hi there, I can’t help but notice that when using the custom ring buffer through pcmreadcallback that the decode buffer size has to be set at an unusually high value to avoid popping and clicking. In my experience it seems like most audio programs work well with input buffer sizes of 128 samples or less for accurate realtime playback, but even the demo userCreatedSound absolutely chokes with a buffer size this small.
Am I doing something wrong here, or is this just a limitation?
2 Likes
There is some information about this in our docs for System::setDSPBufferSize and Studio API Threads white paper.
Hi cameron, do you have more info on this please?
I have this same issue and reading the docs is not helping much.
FMOD chooses the most optimal size by default for best stability, depending on the output type. It is not recommended changing this value unless you really need to. You may get worse performance than the default settings chosen by FMOD.
System::setDSPBufferSize
The FMOD software mixer mixes to a ringbuffer. The size of this ringbuffer is determined here. It mixes a block of sound data every ‘bufferlength’ number of samples, and there are ‘numbuffers’ number of these blocks that make up the entire ringbuffer. Adjusting these values can lead to extremely low latency performance (smaller values), or greater stability in sound output (larger values).Warning! The ‘buffersize’ is generally best left alone. Making the granularity smaller will just increase CPU usage (cache misses and DSP network overhead). Making it larger affects how often you hear commands update such as volume/pitch/pan changes. Anything above 20ms will be noticeable and sound parameter changes will be obvious instead of smooth.
Hi there, resuming this thread as I’m still having this issue and wanted to check if there is any workaround I could use to solve it.
As was said in the first post a large decode buffer size needs to be set in order to make the PcmReadCallback work without producing any popping or clicking.
I’ve tested this also with the user_created_sound example and the minimum buffer size which is not producing any sound artefacts is 2048 (using 44100 as default sample frequency) and 1024 (using 48000). This will translate in a latency of ~170ms, which is already quite important.
I’m now trying to speed up the playback reaching a maximum of 4 times the original speed.
To do so I’m using the Channel::setFrequency function, setting the new frequency to default frequency by speed (e.g. 48000 x 4).
This correctly speed up the playback to the desired speed but it plays fine and without artefacts only if I set the default buffer size to at least 8192, increasing the latency to around ~500ms which is really a lot.
I’ve also tried to set a different buffer size using System::setDSPBufferSize but this is not having any impact on the experienced latency or the minimum buffer size that can be set in order to avoid pops and clicks in the PcmReadCallback.
Is there any way to solve this issue?
Thank you very much
Changing the playback rate shouldn’t cause artifacts, lets try to figure out why you are getting artifacts.
Are you getting sound artifacts in the user_created_sound example when using Channel::setFrequency or is that in a separate project?
Can you share your code around the sound creation and callbacks?