Audio crackling on some machines on WASAPI

[matpow2]

We've tried using this for our game, and multiple people are reporting crackling on their machines with WASAPI. DirectSound is fine. We've tried upping the buffer duration to 200ms and the period count to 4, but the crackling persists.

Using default duration/period, one machine had issues when using the following native format: 48000Hz, f32, 5.1. These are the values of the device:

device.internalChannels: 6
device.internalSampleRate: 48000
device.internalFormat: 5
device.format: 5
device.channels: 2
device.sampleRate: 44100
device.bufferSizeInFrames: 1197
device.periods: 2

[mackron]

Thanks, I'll check this out.

[mackron]

I think I may have fixed this, but I don't currently have a surround sound device to check this. Checkout the "dev" branch and see how that goes. It was just me being stupid and not testing stereo-to-surround mixing properly 👎.

If this does not fix the problem, may I ask if any of your users have described what the crackling sounds like? Is it just like a tiny intermittent crackle every half a second or so, or is it more severe like every millisecond?

If possible, posting the same information you posted above for another user(s) who is having the same issue would be very helpful.

Thanks for your help and the bug report! If that change fixes it I'll bump the version and do a new release right away.

[matpow2]

Example: https://www.youtube.com/watch?v=E7rfIpm3E_c&feature=youtu.be

User description:

1. http://steamcommunity.com/app/393520/discussions/0/1693785669851889672/
2. http://steamcommunity.com/app/393520/discussions/0/1693785669845331439/?ctp=2#c1693785669850451354
3. Slightly unrelated, but could be due to WASAPI as well? http://steamcommunity.com/app/393520/discussions/0/1693785669851769517/

FYI, on Windows, we switched from SDL2 to mini_al on "v1.12" using DirectSound/WASAPI backends, then switched to only using DirectSound with the "v1.12 hotfix".

It seems like the SDL2 audio backends on Windows aren't battle-tested, even though the Linux/Mac backends seem fine. mini_al gave us an immediate solution that seemed to work. Thanks for saving our Iconoclasts launch! :)

EDIT: I'll try the mini_al dev branch with a few people first to see if that messes anything up. I'm a little wary of pushing the WASAPI backend again, but it seems to have less latency, so may be worth it.

[mackron]

Yep, that's pretty severe crackling - it's basically white noise. I'm sorry you had to deal with that...

Am I correct in assuming you are initializing your mal_device object like so:?

device.format = mal_format_f32;
device.channels = 2;
device.sampleRate = 44100;

Are you or any of your developers able to reproduce this? I'm fairly confident the fix I just did will fix the problem, but I don't want to make any guarantees before reproducing it myself or with another developer.

Just out of curiosity, what was the issue you were having with SDL2 on Windows? It's just that mini_al has an SDL backend as a last resort fallback, so it's got me curious now :)

[matpow2]

Yep, that's how we initialize it.
I haven't been able to reproduce it myself, but I've been messaging some users directly.
I'll send them a few builds to see if the WASAPI backend has been fixed.
Thanks a lot for the help!

We had audio crackling on SDL2 as well when using the WASAPI backend, but no similar reports from Linux/Mac users. Switching to DirectSound helped, but we had to use more than 2048 samples to not get crackling (perhaps because SDL2 uses DirectSound8 which doesn't support cursor notifications in some cases?). mini_al seems to do the proper thing by exposing periods/buffer sizes (similarly to OpenAL-Soft which is excellent), and seems to have less latency compared to SDL2, so I think we'll stick with it :)

[matpow2]

I just checked using Razer Surround (which adds virtual 7.1 surround), and the noise seems to be fixed :) I could hear the noise in the non-dev branch.

[mackron]

That's good to hear! I'm trying a few things on my end as well.

Regarding the USB issue, that bug report is a bit too vague. If he's plugging in his USB device while the game is running it won't work (unless you yourself have added functionality for hot-swapping devices at run-time at a higher level).

Does the game always use the default device, or do you allow users to choose the output device? If you are forcing the default device, make sure you pass NULL as the deviceID parameter to mal_device_init(). In any case, a log with his internal rate/channels/format would be very helpful if at all possible.

[matpow2]

I'll try to get in touch with him. As always, hard to get a 1-on-1 with users and use up their time :)

There was a similar bug report from someone on our Discord server (when we still used SDL2). His issue seemed to be that he needed to run the application in administrator mode to have his Razer headphones ("Razer Kraken 7.1 Chroma v2") working. For some reason, the headphones were able to be used by DirectSound but not WASAPI due to init failure. Now that we use mini_al, I don't think that should be a problem, since we do something like this:

    static mal_backend backends[] =
    {
        // mal_backend_wasapi,
        mal_backend_dsound,
        mal_backend_winmm,
        mal_backend_null
    };
    mal_uint32 backend_count = sizeof(backends) / sizeof(backends[0]);

    mal_context_config context_config = mal_context_config_init(on_mal_log);
    mal_device_config config = mal_device_config_init_playback(
        mal_format_f32,
        2, 44100, mal_audio_callback);

    bool found_backend = false;
    for (unsigned int i = 0; i < backend_count; ++i) {
        mal_backend b = backends[i];
        const char * bname = mal_get_backend_name(b);
        if (mal_context_init(&b, 1, &context_config, &context) != MAL_SUCCESS) {
            chowlog << "Skipping " << bname << '\n';
            continue;
        }
        if (mal_device_init(&context, mal_device_type_playback,
                            NULL, &config, NULL, &device) != MAL_SUCCESS)
        {
            chowlog << "Skipping 2nd " << bname << '\n';
            mal_context_uninit(&context);
            continue;
        }

        chowlog << "Found backend: " << bname << '\n';
        found_backend = true;
        break;
    }

    if (!found_backend) {
        chowlog << "Did not find backend\n";
        quit_audio();
        return;
    }

    if (mal_device_start(&device) != MAL_SUCCESS) {
        chowlog << "Failed to start playback device.\n";
        mal_device_uninit(&device);
        mal_context_uninit(&context);
        quit_audio();
        return;
    }

... so I think even if WASAPI could not be initialized with the device, it should still fallback to DirectSound? In any case, I'll try to get in touch with them to test the fixed WASAPI backend.

[mackron]

Yes, that loop logic looks fine to me. I would also expect the problem from Discord to be fixed with that initialization logic. I'll be surprised is the person from Steam will have their issue resolved with that change I made earlier.

[mackron]

I was able to reproduce the crackling issue and indeed that earlier change seems to have fixed it for me also. I'm going to bump the version now, but will leave this issue open pending further investigation into that USB issue.

[mackron]

@matpow2 Any feedback on this? If not I think I'll close this issue now just to keep everything clean.

[matpow2]

We are still using the DirectSound backend in Iconoclasts. I think we will try pushing an update with the WASAPI backend next week, and if people complain, we'll know if there's still work to be done :)
If you want, we can close this issue, and I'll open a new one if I find anything!

[mackron]

I'm going ahead and closing this issue. @matpow2, if you get any more bug reports feel free to re-open this issue or create a new one.

Thanks for the help figuring this one out!