Sound glitches in non-vsync modes with desktop composition enabled

[mark_k]

Testing 2.5.1b4 in Windows Vista SP2, I noticed the sound glitches after a while. The problem only seems to happen with non-vsync modes and desktop composition enabled, not with the Classic theme. This isn't beta-specific, the same seems to happen with 2.5.0. The SND indicator value slowly decreases until there are glitches in the sound. Happens with DirectSound and WASAPI EX.

Generally: Vista SP2, Nvidia driver, Aero theme. Desktop refresh rate ~49.92Hz according to Nvidia control panel. Intel HD audio. Stereo, 100% separation, interpolation sinc, audio filter emulated (A500), frequency 48kHz. WinUAE priority above normal. Windowed output, no vsync. Happens with no buffering or triple buffering.

With DSound: Primary Sound Driver, buffer size 10: Sound indicator in status bar starts at around 0, but gradually (very slowly) decreases. CPU reading is near-constant around 26% with TLC Powertrax demo running. It takes several minutes for the SND indicator to decrease to -40%. It got to -41% and I heard the first glitches/crackles then. The SND indicator briefly changes from black to grey. SND indicator remained at -41/%-40% with very occasional glitches.

Pausing and un-pausing emulation (e.g. tapping Pause key twice quickly) "resets" the SND indicator to 0%. Sound is then glitch-free until the indicator reaches about -40% again.

Smaller buffer settings are similar except the SND indicator decreases more quickly. With buffer 8 it takes a couple of minutes to reach -40% and glitch.

Buffer size 1: again crackles when it reaches about -40%. Value seems to vary widely between about -41% to -1%

WASAPI EX, buffer 8: SND indicator decreases quickly down to about -92%, get frequent glitches then. Again, tapping Pause twice resets SND indicator to 0, then it decreases again.

WASAPI EX, buffer 10: still decreases (much faster than DirectSound with buffer 10). Get glitches at about SND -95%.

Now the interesting difference. If I set output to windowed low-latency vsync, the SND indicator remains between -2% and +2% (CPU usage ~55%) for WASAPI EX, buffer 10. No glitches. Changing buffer to 4: SND varies between -23 and +1%, no glitches. Even with buffer 1, no glitches. SND varied between -22 and +7%.

Legacy vsync: 100% CPU use, no glitches with DirectSound. WASAPI EX glitches with sound buffer 4. No glitches with buffer 10, SND indicator decreases from 0% to -8% then back to 0% repeatedly.

After changing to Classic (non-compositing) theme, no vsync, no buffering, WASAPI EX buffer 6: no glitches, SND between +15% and -7%.


I wonder... could this problem be because with Aero desktop composition enabled, that actually forces WinUAE to be synced with the host frame rate, though it thinks it's not? And the host frame rate won't exactly match the Amiga frame rate. That could explain why I didn't get the crackling with vsync modes under Aero.

[Toni Wilen]

Does it stop happening if you have >50Hz (60Hz) desktop refresh rate?

[mark_k]

Yes, it does seem to. I get options for 60Hz, 59Hz and 50Hz for each desktop resolution, and when using 59 or 60Hz the problem isn't there.

[BTW if you have an Nvidia card I can write about how to override your monitor's EDID data which allows easy selection of both 50Hz and 60Hz modes without needing to add lots of custom resolutions in Nvidia settings.]

I did notice a minor issue with WASAPI EX output. On starting emulation (with 60Hz desktop) and booting the TLC Powertrax demo, when the demo starts the SND indicator reads about -95% then steadily increases up to about +75%. Pressing Pause twice resets it to near zero. Whereas with DirectSound the SND indicator reads near 0 when the demo starts.

[Toni Wilen]

Only triple buffering mode in windowed mode forces vsync wait (D3DPRESENT_INTERVAL_ONE), any other mode uses D3DPRESENT_INTERVAL_IMMEDIATE = it should never wait. Unless you have some forced vsync option set in display driver control panel?

btw, do you really have to use Vista? "No one" uses it today for games (=anything weird can happen).

EDIT:

Windows 8, NVidia and secondary monitor at 1920x1080i25: No slowdowns but triple buffering causes doubled CPU usage, possibly related. (double works normally) Usually display drivers have 1-3 buffer queue so that vblank wait for cause immediate slowdowns.

[mark_k]

I tried forcing vsync off and setting maximum pre-rendered frames to 0 in Nvidia settings but that didn't change things.

Next I tried setting the desktop to 49Hz and 51Hz. In both cases the sound problem wasn't present. I could see the Amiga display "judder" about once a second corresponding to the ~1Hz difference between Amiga and PC frame rates. So it seems the sound problem is only present when the desktop refresh rate is close to 50Hz when emulating a PAL Amiga. (I set WinUAE to emulate an NTSC machine and got the sound problem with the Windows desktop set to 60Hz too.)

Perhaps on my system at least, Windows and/or the Nvidia driver are forcing vsync when the rate at which WinUAE sends frames is close enough to the Windows desktop rate???

Windows Vista is just what came with my laptop.

Edit: the problem happens in windowed and full-window modes with desktop composition enabled. It doesn't happen in full-screen mode, presumably because Windows disables desktop composition then. It doesn't happen when WinUAE is minimised either.

[Toni Wilen]

Hmm.. There is always a problem if vsync is forced and display update rate is smaller than emulated rate.

It probably needs some fix but I don't know how to handle this because it is probably impossible (=depends on drivers etc..) to know current "frame rate" limit. (Just attempting to test it by drawing few frames isn't going to be reliable enough)

Unfortunately this is something that no games need to care, they generate as many frames as possible, they don't have some minimum limit.

[mark_k]

Maybe the reason why Windows seems to force vsync when an application renders frames at close to the desktop refresh rate is to avoid occasional skipped or doubled frames during video playback.

Of course in this case it's not ideal since WinUAE doesn't know about that. In the absence of an automatic solution some more user options could be added. Examples: option to disable desktop composition when WinUAE is active. Option to assume that when the desktop refresh rate is close to the Amiga refresh rate, Windows will force vsync. Then you'd handle sound similarly to the way the current WinUAE vsync modes work.

[Toni Wilen]

Originally Posted by mark_k

option to disable desktop composition when WinUAE is active. Option to assume that when the desktop refresh rate is close to the Amiga refresh rate, Windows will force vsync. Then you'd handle sound similarly to the way the current WinUAE vsync modes work.

NO! Assuming = EXTREMELY BAD IDEA. Very high danger of breaking things with future service packs or Windows versions or driver versions.

EDIT: Also it is considered very impolite to switch off composition and I never implement these kinds of stupid workaround options to GUI. And no "normal user" knows when to use it anyway so there is no point and not that normal users can switch it off manually.

[mark_k]

I don't know whether it would affect the sound issues, but...

Using the DwmSetPresentParameters function you can specify fUseSourceRate, and rateSource is the number of frames per second expressed as a ratio (so doesn't have to be an integer) for DWM to present.

WinUAE could call DwmSetPresentParameters on each frame rate change to tell Windows what the Amiga frame rate is.

[Toni Wilen]

Not much documentation available..

But I think I found your problem: "Flip Mode Presentation of Direct3D 9Ex is an improved mode of presenting images in Direct3D 9Ex that efficiently hands off rendered images to Windows 7 Desktop Window Manager (DWM) for composition"

WinUAE uses Direct3D9Ex if available = get rid of Vista

Also MS says Queued present model is being deprecated after Windows 8 and programs should use DXGI. So not much point in using DwmSetPresentParameters() now.

Perhaps DwmEnableMMCSS() also helps (in some other windowed mode issues).

[mark_k]

It turns out that the sound glitch problem doesn't only occur with desktop composition enabled. With the Classic theme, I get the slowly-decreasing SND% and glitches when using both triple buffering and graphics API Direct3D. Something (Vista or Nvidia driver?) is definitely forcing vsync in that case, because the picture is rock-solid.

With all other combinations of API/buffering settings I can see a glitch line which moves up the screen since the emulated Amiga frame rate isn't identical to the desktop refresh rate, and the sound doesn't glitch.

Edit to add: Also, the case where WinUAE shows 100% CPU in the status bar doesn't seem to reflect the actual CPU usage. For example with Windows Classic theme, D3D, no or double buffering: ~22% CPU. D3D, triple buffering: 100% CPU, sound glitches. But the CPU usage figure according to Task Manager is about 38% average in both cases.