CUzeBox - The new official Uzebox emulator

[CunningFellow]

My speakers don't click. But my speakers are a bit strange and barely have any volume.

[Jubatian]

But right upon initial startup of cuzebox there are a couple loud popping noises, that sound almost like when you are plugging or unplugging a 3.5mm audio cable connected to powered speakers.

One additional thought... Does this definitely happen with any game? Some games have poor initialization, resulting in driving the speaker low for a short while, which the emulator of course mimics. It could be that different drivers initialize differently (taking different time for getting up and running, actually taking the samples), so they swallowed this earlier, and with WASAPI, they don't.

[Artcfox]

But right upon initial startup of cuzebox there are a couple loud popping noises, that sound almost like when you are plugging or unplugging a 3.5mm audio cable connected to powered speakers.

One additional thought... Does this definitely happen with any game? Some games have poor initialization, resulting in driving the speaker low for a short while, which the emulator of course mimics. It could be that different drivers initialize differently (taking different time for getting up and running, actually taking the samples), so they swallowed this earlier, and with WASAPI, they don't.

It doesn't matter which game: https://youtu.be/E3d_h7sELZA

The other fix I proposed with setting that environment variable doesn't create these loud popping sounds.

[Jubatian]

It doesn't matter which game: https://youtu.be/E3d_h7sELZA

The other fix I proposed with setting that environment variable doesn't create these loud popping sounds.

OK, I see, that's definitely an initialization pop then. I asked since I have a few games, mostly things compiled with older kernels, which pop on startup, but which can not really be fixed as the Uzebox itself drives the PWM that way.

Did another attempt, trying to work around something which just shouldn't happen, but probably could, causing the pops. Really would like to get WASAPI working (if that's SDL / in the end, Microsoft actually wants to shove on us, eventually it has to be supported), if not possible, probably will go on a different route than injecting an environment variable (scan audio drivers, select the preferred one which gets sound to speakers and is not WASAPI, unless only WASAPI is available, then choosing that, a pop on startup is better than no sound at all).

[Artcfox]

It doesn't matter which game: https://youtu.be/E3d_h7sELZA

The other fix I proposed with setting that environment variable doesn't create these loud popping sounds.

OK, I see, that's definitely an initialization pop then. I asked since I have a few games, mostly things compiled with older kernels, which pop on startup, but which can not really be fixed as the Uzebox itself drives the PWM that way.

Did another attempt, trying to work around something which just shouldn't happen, but probably could, causing the pops. Really would like to get WASAPI working (if that's SDL / in the end, Microsoft actually wants to shove on us, eventually it has to be supported), if not possible, probably will go on a different route than injecting an environment variable (scan audio drivers, select the preferred one which gets sound to speakers and is not WASAPI, unless only WASAPI is available, then choosing that, a pop on startup is better than no sound at all).

I just tested the new version and it still has the loud pops.

One of the biggest draws of SDL is because it abstracts away all of the platform differences. I think it's a huge bug in SDL that sound doesn't just work out of the box on Windows.

[Jubatian]

I just tested the new version and it still has the loud pops.

One of the biggest draws of SDL is because it abstracts away all of the platform differences. I think it's a huge bug in SDL that sound doesn't just work out of the box on Windows.

Pfff... No idea then, feels like something beyond whatever I can do when using WASAPI. Yes, I completely agree on that, this thing feels really rushed, many projects having numerous problems with it beyond the initial hurdle that it is suddenly an API which is only content when fed with floating point samples. I think I will give it some further thought and design in the weekend, trying to work around the native prioritization in SDL so the fallbacks still work, but WASAPI is de-prioritized as a last resort if nothing else is available.

With Microsoft, it is impossible to do anything, they are just like that, but SDL shouldn't be just following suit screwing things up. Well, frankly at least in this regard Linux isn't much better with the mess of audio options (Alsa, Pulse, Jack, Esound, probably even some OSS still lingering about, and who knows what else...).

[Jubatian]

Did another attempt at it.

This version does the following on SDL2, Windows (SDL1 builds are unaffected, including Emscripten. Linux builds are minimally affected in that they are now using the SDL2 Audio API instead of the legacy SDL1 API on SDL2 builds):

- If the SDL_AUDIODRIVER environment variable is set, then whatever driver is specified there will be used (it is so possible to select wasapi intentionally).
- Otherwise if in the list of drivers known to SDL, "directsound" exists, then it will be used.
- Otherwise whatever default SDL provides will be used (could be wasapi).

On a system with buggy wasapi (but working directsound), there shouldn't be any problem exhibited related to wasapi (audio should be initialized only once, there is no temporary transitional state where wasapi could be brought up). If this works, I will commit it, and would say, let's forget about this problem, sitting snugly under the carpet, until something breaks again

[Artcfox]

Did another attempt at it.

This version does the following on SDL2, Windows (SDL1 builds are unaffected, including Emscripten. Linux builds are minimally affected in that they are now using the SDL2 Audio API instead of the legacy SDL1 API on SDL2 builds):

- If the SDL_AUDIODRIVER environment variable is set, then whatever driver is specified there will be used (it is so possible to select wasapi intentionally).
- Otherwise if in the list of drivers known to SDL, "directsound" exists, then it will be used.
- Otherwise whatever default SDL provides will be used (could be wasapi).

On a system with buggy wasapi (but working directsound), there shouldn't be any problem exhibited related to wasapi (audio should be initialized only once, there is no temporary transitional state where wasapi could be brought up). If this works, I will commit it, and would say, let's forget about this problem, sitting snugly under the carpet, until something breaks again

I can confirm that the popping sounds are gone on Windows when I swap the packaged DLL with the latest version!

[Jubatian]

I can confirm that the popping sounds are gone on Windows when I swap the packaged DLL with the latest version!

Done committed it to the main repo, also replacing the downloads on the top post (the WASAPI workaround doesn't affect them much, though, unless you replaced the SDL library in the package).

[Artcfox]

I can confirm that the popping sounds are gone on Windows when I swap the packaged DLL with the latest version!

Done committed it to the main repo, also replacing the downloads on the top post (the WASAPI workaround doesn't affect them much, though, unless you replaced the SDL library in the package).

Awesome!

Can you package it with the latest SDL libraries? Without them the USB game controllers don't work out of the box on Windows.