I’m trying to update to SDL 2.0.6 - using the binary Windows DLL - but my application is suffering from the ‘sound clicks’ problem: my audio sampling rate is 44100 Hz and I can’t change it. I have read elsewhere that the fix should be to add a SDL_HINT_AUDIO_RESAMPLING_MODE hint but that seems to make no difference.

I’ve attempted to find the official documentation for this hint, but searching the SDL 2.0 Wiki results in the message ‘Your search query “SDL_HINT_AUDIO_RESAMPLING_MODE” didn’t return any results’ (Google didn’t find anything either). Where is it documented, and what is the recommended fix for the sound clicks issue?

I don’t need any of the new features in 2.0.6 and I’m not noticing any shortcomings in 2.0.5 so I will continue to use that for the time being.


Fixing the ticking in the new resampler will require these patches to SDL:

and will probably require this being fixed:

Until those are merged/fixed, I think the only option is to avoid the WASAPI backend and use directsound on Windows, or stick with 2.0.5?

btw the SDL_HINT_AUDIO_RESAMPLING_MODE docs are here:
However - I think those docs need updating to describe the new internal resampler in SDL and when it’s used.

Oh, OK, thanks. I’m surprised and concerned that such a serious fault should have made it into a so-called ‘stable’ release.

Setting SDL_AUDIODRIVER=directsound does indeed seem to fix the fault, but that raises its own issues. Can I do it programmatically (e.g. via a hint; I don’t want to have to launch my app via a batch file)? Why isn’t it the default? Are there any downsides?

That’s not documentation, it’s source code! Call me old-fashioned, but if a feature isn’t documented it isn’t usable. Updating the docs should be an essential element of any new release.


You shouldn’t need a batch file just to set environment variables, you can use SDL_setenv – not documented, but has the same arguments/return values as setenv, except it doesn’t require the c library on win32.

That’s great, thank you, but - and I’m sorry if I seem permanently grumpy - why isn’t such a useful feature documented? Is it likely to be removed in a future version? Is it unreliable? Is it just to be as unhelpful as possible?!

I’m relatively new to SDL but I’m becoming disillusioned. :disappointed:


Don’t give up on SDL; it’s great. The documentation is lagging behind because no one has had the time to update it. SDL is developed by the community in their free time. SDL is free, so you get a lot more than what you pay for. 2.0.6 has caused a lot of problems and the pre-release period should have been longer to iron out the bugs. I’ve rolled back to 2.0.5 and will probably jump to 2.0.7 or 2.1 when it’s released (even if I have to wait 1 or 2 years). But I’ll try this SDL_setenv first to see if it fixes my problem with 2.0.6 (fingers crossed).

1 Like

SDL_AudioInit("directsound"); is the programmatic way to select the directsound backend. (docs: )
You can do it after SDL audio is initialized and it will shut down the wasapi driver.

This should work cross-platform:

if (SDL_AudioInit("directsound") != 0) {
    // directsound not available, use the default backend

That won’t work with SDL_mixer thought, right?

I haven’t tested it but it looks like SDL_mixer should be fine with that, as long as Mix_OpenAudioDevice is called after SDL_AudioInit, SDL_mixer should notice that the audio subsystem is already initialized and not try to init it again:

On the other hand maybe SDL_setenv is cleaner.

I tried this in place of SDL_setenv(“SDL_AUDIODRIVER”, “directsound”, true), and it has no effect. Looks like SDL_mixer does its own SDL_AudioInit, in spite of it being done previously?

^ scratch that - I put the init in the wrong place.

Both methods are working for me. SDL_mixer seems to be happy to have SDL_AudioInit called before Mix_OpenAudio.

1 Like