kcat
Audio Stutters when Windows Sound Device is not 48000Hz
Hey I've found that when my sound device in windows isn't 48000KHz, the audio in my game stutters when there are many active sounds.
Here's my sound device settings in Windows
I've disabled these and the issue still occurs:
- HRTF
- Filters (e.g. low pass)
- EFX effects (reverb)
I also stopped creating the filter/effect slots on startup but that didn't help. No AL/ALC errors were reported
The issue still occurs regardless of whether I set the ALC_FREQUENCY attribute to 48000, 96000 or 192000.
The issue also occurs when setting my sample rate in Windows to 96000KHz.
I also tried restarting my PC after changing to 192000Hz.
Here's a video of the stuttering
It sounds like it's having a hard time keeping up with many sounds playing at once. 192khz is an excessively high sample rate, it's causing OpenAL Soft to process over 4x as many samples per source channel than really necessary. Effects like reverb or HRTF will also greatly increase processing cost as the sample rate increases. For normal listening, there's no point going above 48khz since it well covers the audible frequency range (and even for intermediary output, there's not always a need to have an extended frequency range).
Setting ALC_FREQUENCY won't normally have an effect on Windows, since WASAPI doesn't normally allow streams to play at a different sample rate than the device. I have been meaning to add the ability for OpenAL Soft to do its own resample pass on the output separate from the mixing format, so that it doesn't need to waste time/resources mixing and processing effects at unnecessarily high rates, which would help with issues like this. Though having the device set to 48khz would be better all around since it would avoid having other apps handle such high sample rates too (and possibly improve audio quality).
Thank you, yeah I don't notice any difference in quality above 48khz. I didn't notice any difference in stuttering with HRTF/filters/effects disabled vs enabled as well, it must be the mixer itself that's struggling?
ability for OpenAL Soft to do its own resample pass on the output separate from the mixing format
Does this mean that regardless of what I set ALC_FREQUENCY to, OpenAL will always mix sounds at the sample rate of the user's sound device?
Yep I've shared instructions for my players on how to change their device to 48khz and that fixes all stuttering. Some user's sound devices have a minimum of 96khz unfortunately, so I added a setting in-game to change ALC_FREQUENCY to 96khz. They said it stopped 95% of all sound stuttering - could there be something else going on here, as previously there was more stuttering with ALC_FREQUENCY at 48khz and their sound device at 96khz?
Thank you, yeah I don't notice any difference in quality above 48khz. I didn't notice any difference in stuttering with HRTF/filters/effects disabled vs enabled as well, it must be the mixer itself that's struggling?
There might be a timing issue too, since the mixer needs to wait until the device says more samples are needed, at which point it has a limited amount of time to get it done. Although I would still expect a change if HRTF was disabled since that would be quite a time sink, so I'm not completely sure. In your video, it is behaving as I'd expect in this scenario; it's fine when there's just a couple sounds, then the stuttering starts as more sounds play at once, then it goes away when there's fewer, and starts again when there's more. Do you notice any times where it stutters with only a few sounds playing (when it would otherwise be fine with that many), or periods where it plays fine despite a lot of sounds playing (when it would otherwise be stuttering with that many)?
Does this mean that regardless of what I set
ALC_FREQUENCYto, OpenAL will always mix sounds at the sample rate of the user's sound device?
Currently on most Windows systems, yes, unless the user has an APO installed which would allow a WASAPI stream to be resampled, or if Windows adds that feature itself. OpenAL Soft will pass along the request to WASAPI, but that will simply report back that the requested sample rate isn't usable and say to use the device's rate instead. Though as I mentioned, I do intend to make OpenAL Soft able to do its own resample pass so it can mix at the requested rate, regardless of what WASAPI says is needed. So at some point, it will likely have an effect, one way or another. After creating the context, you can query the ALC_FREQUENCY attribute from the device to see what it ended up using:
ALCint rate;
alcGetIntegerv(device, ALC_FREQUENCY, 1, &rate);
Yep I've shared instructions for my players on how to change their device to 48khz and that fixes all stuttering. Some user's sound devices have a minimum of 96khz unfortunately, so I added a setting in-game to change
ALC_FREQUENCYto 96khz. They said it stopped 95% of all sound stuttering - could there be something else going on here, as previously there was more stuttering withALC_FREQUENCYat 48khz and their sound device at 96khz?
That's certainly odd. Perhaps it's an intermittent issue, where even though nothing is actually different about the stream, sometimes it behaves better than others regardless. I would need to see a trace log to get a better idea of what's going on, but I wouldn't expect a difference in behavior as a result of changing that request.
If you set the ALSOFT_LOGLEVEL environment variable to 3 when you run the game, OpenAL Soft will write a trace log to stderr. You can also set the ALSOFT_LOGFILE environment variable to a full path+filename to have it create the named file and write the log there instead (make sure you have write permissions to the directory so it can create the file).
Seeing a trace log from both the "good" result when specifying 96khz with little stuttering, and the "bad" result when specifying 48khz with more stuttering, would be useful.