Windows/Latest FMOD Studio 1.08/Visual Studio Community 2015
I’ve setting up FMOD at 44,100/22,050 khz, from 1000 to 128 channels but some users still get audio popping issues when they’re live streaming the game, regardless of the initial settings.
Even if just streaming one looping audio event, there are occasional blips, as though a buffer wasn’t fully loaded or wrapped incorrectly?
I don’t think they are audible to the user (and thus maybe not even FMOD’s problem) but the capturing device can’t seem to capture the audio correctly and I’m really not sure why?
It isn’t a specific OBS issue since some people can stream it fine and others can’t. But the ones who can’t stream it, can still stream other games with perfect audio. So I don’t think its their setup that is flawed.
I’m really struggling - Any ideas?
EDIT: I’m trying setDSPBufferSize now to see if I can dial in a better setting for some users. It doesn’t appear to help to popping, to double buffer size and num buffers.
What else can I try?
EDIT 2: Seems the popping is coming from the mic/headset device but if it only happens with my game, what can I determine? Is the default thread priority for FMOD going to be set to high? highest? Should I try to manually set thread priority to solve a problem that now seems to be coming from another device? Should I give the user the ability to select these things? If so, what should I default them to?
The live stream just inserting some heavy thread priority process i’m guessing, and its just interfering with FMOD’s threads. If audio was to be captured, there’s ways to do that in fmod, but a 3rd party app, its hard to defend against that. Altering the buffer size is about the only thing I can thing of (the numbuffers btw, not the buffer size or audio granularity will degrade), but tbh the capture program should have some settings to stop it being so invasive.
Some other things you could try is switching the output mode , ie from FMOD_OUTPUTTYPE_WASAPI to DSOUND , that might do something.
What version of FMOD is this with btw? If its really old, some changes were made to the WASAPI output mode that might be relevant
Forced DSOUND and changing numbuffers does not solve the issue. Oddly enough, running the USB mid through a powered USB hub seems to have solved the issue. The problem remains: how could my software cause that response? I wonder: if default thread priority for FMOD is higher than the thread priority for some USB audio systems and my game is starving the USB audio drivers of thread time then thats why the issue would show up with that device rather than my game. But now: if I lower thread priority of FMOD/game, will the game will be starved of resources? Even starting the game with 22khz/128 channels, didnt seem to relinquish enough resources to make any difference.
sounds like if you try a bunch of things with fmod and nothing helps (and to the ear FMOD is stable/not glitching?), then its probably a problem with the program itself.
FMOD runs a time critical thread for its mixing, and the thread the capture program uses doesn’t run at a high enough priority, and doesnt buffer adequately to avoid glitching. We could have a lower priority mixing thread, but that would just cause audible glitches and is not really useful.
Does the stream program have its own priority/buffer size settings?
The live stream just inserting some heavy thread priority process i’m guessing, and its just interfering with FMOD’s threads. If audio was to be captured, there’s ways to do that in fmod, but a 3rd party app, its hard to defend against that. Altering the buffer size is about the only thing I can thing of (the numbuffers btw, not the buffer size or audio granularity will degrade), but tbh the capture program should have some settings to stop it being so invasive.
Some other things you could try is switching the output mode , ie from FMOD_OUTPUTTYPE_WASAPI to DSOUND , that might do something.
What version of FMOD is this with btw? If its really old, some changes were made to the WASAPI output mode that might be relevant