This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Why SDL_setenv workaround is BAD (Screenshot_35.png, image/png, 2018-02-15 14:38:14 +0000, 6036 bytes)
• A working test of latest SDL 2.0.9 for Windows (adlmidi-test.zip, application/zip, 2018-11-14 13:05:10 +0000, 1226516 bytes)

Reported in version: HG 2.1
Reported for operating system, platform: Windows 10, x86_64

Comments on the original bug report:

On 2018-01-26 14:59:50 +0000, Vitaly Novichkov wrote:

WASAPI gives no sound on Windows 10 as that was reported here on one of my projects:
Wohlstand/libADLMIDI#32

He had to use pre-built SDL2 from the libsdl.org's downloads. The sound appears only when we are forcing SDL2 to use DirectMusic or WinMM through environment variables.

Also, the latest version of libSDL2 gives a very dirty playback on Wine when WASAPI is in use.

Everything was built with using of CMake. When WASAPI is worked fine, it produces a choppy sound playback when using powerful codecs such as libADLMIDI which uses very accurate Nuked OPL3 chip emulator, which is working fine on DirectSound or WinMM.

As those troubles are occupied with using of WASAPI, I want to have ability natively produce WASAPI-less SDL2 builds out of pre-patching of configure scripts or CMakeLists.txt to do that. Another issue I have created for this feature request:
https://bugzilla.libsdl.org/show_bug.cgi?id=3798

On 2018-01-30 12:38:07 +0000, Olav Sørensen wrote:

Yes, SDL2 started to get audio problems when they started using WASAPI on Windows. My programs also get choppy/cracking/popping audio on some machines, and making the audio buffer size higher doesn't fix it. Very frustrating... It was all good before the transition, but then you didn't get the "hot swap" audio device support.

On 2018-01-30 12:44:30 +0000, Olav Sørensen wrote:

The worst part is that there's no way to turn WASAPI off unless you build SDL2 yourself. Very annoying though, because I don't want to rebuild SDL2.dll, I want to use the original one where they used the optimal compiler settings etc.
Having a hint for disabling it would be fantastic, as WASAPI on SDL2 is known to have problems for some people, including me.

On 2018-01-30 13:03:47 +0000, Ryan C. Gordon wrote:

(In reply to Olav Sørensen from comment # 2)

Having a hint for disabling it would be fantastic, as WASAPI on SDL2 is
known to have problems for some people, including me.

SDL_setenv(“SDL_AUDIODRIVER”, “directsound”, 1);
SDL_Init(SDL_INIT_AUDIO);

--ryan.

On 2018-01-30 13:18:48 +0000, Vitaly Novichkov wrote:

(In reply to Olav Sørensen from comment # 2)

Having a hint for disabling it would be fantastic, as WASAPI on SDL2 is
known to have problems for some people, including me.

SDL_setenv(“SDL_AUDIODRIVER”, “directsound”, 1);
SDL_Init(SDL_INIT_AUDIO);

--ryan.

Yeah, but (to don't break compatibility with other platforms, or SDL will cry for an unknown audio driver)

#ifdef _WIN32
SDL_setenv(“SDL_AUDIODRIVER”, “directsound”, 1);
#endif
SDL_Init(SDL_INIT_AUDIO);

Also, It's my clunky but working workaround I use in my project to avoid WASAPI appearance in building libraries.
https://github.com/WohlSoft/PGE-Project/blob/master/_Libs/_sources/___build_script.sh#L139-L142(In reply to Ryan C. Gordon from comment # 3)

On 2018-02-15 14:38:14 +0000, Vitaly Novichkov wrote:

Created attachment 3170
Why SDL_setenv workaround is BAD

Okay, the using of SDL_setenv workaround is BAD.

Why?

On some computers DirectSound is not available, therefore WinMM will be is the use. DirectSound is a better choice than WinMM, but in some cases usage of DirectSound is impossible.

So, the best solution is an ability to natively disable WASAPI which is still glitchy on many systems.

On 2018-10-01 17:03:04 +0000, Sam Lantinga wrote:

Do you have a test case to reproduce this problem? We haven't seen any problems with WASAPI in our applications and DOTA 2 is starting to use it as the default audio driver.

The WASAPI has a number of benefits on modern systems (hot plugging, better resampling support, etc.) and is the native Windows API, which makes it preferred over the other options.

On 2018-10-01 17:09:14 +0000, Vitaly Novichkov wrote:

Yes!

Try to compile this project:
https://github.com/Wohlstand/libADLMIDI

Use next setup (no matter MinGW or MSVC. Myself I always using MinGW and having the issue with WASAPI case):

md build
cd build
cmake -DWITH_MIDIPLAY=ON ..
make -j 5

Then, force SDL2 to use WASAPI and try to play any MIDI file via "adlmidiplay.exe" utility, for example:

set SDL_AUDIODRIVER="wasapi"
adlmidiplay.exe "C:\Windows\Media\onestop.mid" -fp --emu-nuked 68

On 2018-10-01 17:12:35 +0000, Vitaly Novichkov wrote:

P.S. The source code of simple player itself where is a usage of SDL Audio was done:

https://github.com/Wohlstand/libADLMIDI/blob/master/utils/midiplay/adlmidiplay.cpp

On 2018-10-01 17:13:33 +0000, Vitaly Novichkov wrote:

Absolutely similar issue is on my fork of SDL Mixer where the plugin for libADLMIDI is here:

https://github.com/WohlSoft/SDL-Mixer-X/blob/master/src/codecs/music_midi_adl.c

On 2018-10-01 17:15:33 +0000, Vitaly Novichkov wrote:

One note: Most of the issues are happens when you are using Nuked OPL3 emulator chosen on the libADLMIDI side. When the DOSBox OPL3 emulator was chosen, it has fewer issues on real Windows 7.

The test with DOSBox emulator:

set SDL_AUDIODRIVER="wasapi"
adlmidiplay.exe "C:\Windows\Media\onestop.mid" -fp --emu-dosbox 68

On 2018-10-02 09:51:33 +0000, Vitaly Novichkov wrote:

By the mean irony, absolutely SAME thing outputs audio stream fine through WinMM and DirectSound overlays.

On 2018-11-07 13:43:00 +0000, Vitaly Novichkov wrote:

Quick question: does it's a matter which compiler was used? This bug is reproducible when using vanilla MinGW toolchains (http://mingw.org/), but I have didn't tested MinGW-w64 case (I making 64-bit builds through it, but I have didn't tested it yet myself). I never using MSVC except for super-rare cases.

On 2018-11-14 10:17:54 +0000, Michel Rouzic wrote:

So just call a function like this when you initialise the audio then?

void sdl_init_audio_not_wasapi()
{
int i;

SDL_AudioQuit(); // quit the current audio driver, probably wasapi

// Init the first driver that isn't wasapi
for (i = 0; i < SDL_GetNumAudioDrivers(); ++i)
if (strcmp("wasapi", SDL_GetAudioDriver(i))) // if the driver isn't called "wasapi"
{
SDL_AudioInit(SDL_GetAudioDriver(i)); // initialise it
return ;
}
}

No real need for #ifdef _WIN32 since all it does is go through the list of drivers and pick the first one not called "wasapi".

For reference here for me the list of drivers is:
0: wasapi
1: directsound
2: winmm
3: disk
4: dummy

So this function picks directsound and would fall back to winmm were that to be missing.

On 2018-11-14 13:05:10 +0000, Vitaly Novichkov wrote:

Created attachment 3494
A working test of latest SDL 2.0.9 for Windows

Okay, just now I have tried to test on all my systems, and I see that WASAPI is now much better than in previous times!

I have built the ready-to-use test that was failed with the previous SDL2 versions, but works fine on latest!

On 2018-11-14 13:12:33 +0000, Vitaly Novichkov wrote:

Okay, I can see next:

 - Audio wanted (format=S16,samples=3528,rate=44100,channels=2);
 - Audio obtained (format=F32,samples=661,rate=44100,channels=2)

Looks like WASAPI accepts Float32-only and can't PCMS16.

In past, I have passed S16 stream as-is with no any conversions. For now, I doing the generating of the stream into the requested format to avoid any post-conversions of output. I have done tests on the next platforms:

• Wine 3.20 (set into Windows 7)
• Windows 10
• Windows 7

And now everything works fine!

I also remember that some time ago you had troubles with sample conversions, and one of them I have fixed by myself.

On 2018-11-14 18:19:28 +0000, Michel Rouzic wrote:

I was using the 2.0.8 SDL2.dll until today and it worked fine, but since I just switched to the 2.0.9 SDL2.dll I get the WASAPI bug and I now have to call the function I posted above to skip WASAPI. It made the sound play back about two times too fast and all cracked and skippy, so there seems to be a regression in the 2.0.9 DLL (compiling against the 2.0.9 .lib but still using the 2.0.8 DLL worked fine).

And yet I tried Vitaly's MIDI test and all 3 outputs worked fine, so maybe it's down to my code. I requested a sample rate of 44100, AUDIO_F32 format, 2 channels, a buffer of 2048 samples and only called the legacy SDL_OpenAudio() function.

On 2018-11-14 18:34:08 +0000, Michel Rouzic wrote:

Okay I should have looked at my own logs, it says I asked for 2048 samples but it gave me 981, and the rest of my code didn't take that new size into account. Before WASAPI I never failed to obtain the 2048 samples I asked for so that was never a problem, but it's just down to bad coding from me. So problem solved.

On 2019-05-18 18:48:54 +0000, Ryan C. Gordon wrote:

Tagging a bunch of bugs with "target-2.0.10" so we have a clear list of things to address before a 2.0.10 release.

Please note that "addressing" one of these bugs might mean deciding to defer on it until after 2.0.10, or resolving it as WONTFIX, etc. This is just here to tell us we should look at it carefully, and soon.

If you have new information or feedback on this issue, this is a good time to add it to the conversation, as we're likely to be paying attention to this specific report in the next few days/weeks.

Thanks!

--ryan.

On 2019-06-09 01:35:53 +0000, Sam Lantinga wrote:

It looks like this is taken care of now.

Thanks everyone!