Windows 10 FCU issues with WinUAE

[hexaae]

BUG: trashed and slow audio after switching back and forth for a while from WB (Picasso emu) <-> native PAL/NTSC modes.

Hi Toni,
I'm experiencing some issues with WinUAE (tested 2.5.2, 3.5.0, 3.6.0b7) and Windows 10 FCU + recent Nvidia drivers 388.xx.

I use WB desktop screen in 1920x1080 32bit as emulated Picasso with P96 drivers 60/75Hz in WB3.9:Devs/monitors (full borderless window mode) + full screen for native PAL/NTSC 50/60Hz resolutions with games etc. So every time I switch screens there is a small audio delay with sound trashed... The problem is that since Windows CU or FCU (I'm not sure) sometimes this trashed and slow audio issue never stops and goes on even after I reboot WB and goes away only when I fully quit and restart WinUAE.

I did some tests to isolate the source and noticed that disabling (from Device Manager) gfx card drivers (Nvidia 388.31 + GeForce Experience) I CAN'T reproduce the issue, so my conclusion is it can be something with video timing and video drivers and the way Windows 10 (F)CU now handles screens.

Tested the same identical system migrated to another laptop with Intel HD gfx + Win 10 AU and wasn't able to reproduce the issue.

Here is a video on YT where I reproduced the issue switching back and forth from WB desktop to native resolutions. You can hear the sound slowdown starting from min 1:08:
[ Show youtube player ]

...running just Delitracker + another program on a separate PAL screen and starting switching screens quickly: after some time you'll hear the sound getting slow and trashed ONLY on the WB desktop (or at least is more evident in non-native modes). If I reboot WB it won't go away. Have to fully quit WinUAE.
Tried also to disable G-Sync from NVidia Control Panel (I've read there can be some issues with g-sync drivers and Win 10 FCU) without success.

How can I help you to debug this?
Attached my cfg and logs....

NVidia 388.31 WHQL (with GeForce Experience installed) + Windows 10 x64 FCU 16299.64
Gaming laptop ASUS G751JY [Intel HM87 Lynx Point, i7-4860HQ, 24GB DDR3L 2133MHz, GTX 980M (GM204M, 10DE-1617/1043-22DA Rev A1, vBIOS v84.04.48.00.39), 4GB GDDR5 (Micron), G-Sync], Windows 10 x64, display: LG Philips LP173WF4-SPD1 (LGD046C) 17", desktop res: 1080p 75Hz, Audio: Realtek, Competition Pro USB arcade joystick SpeedLink SL-6603-SPORTS-EU, XBox One Bluetooth controller, Microsoft PN7-00004 Bluetooth mouse

[Toni Wilen]

Does changing buffers from triple to double change anything? Exact same if you only use windowed modes? Without CPU Idle?

[hexaae]

Still the same trashed audio after some screen switches...
Settings used:



EDIT: tried also setting Windowed 720 568 "No buffering" but nothing changed, CPU Idle set to min/0 (slider moved on the left)

[hexaae]

Is there a special parameter to exclude gfx HW acceleration completely, for testing, in WinUAE?

[hexaae]

I've put WineD3D 2.20 staging libraries in the same dir of WinUAE.exe for testing, and I can confirm it's some obscure bug related to DirectX/rendering: I CAN'T reproduce the issue running WinUAE when using WineD3D DX9 wrapper.
https://fdossena.com/?p=wined3d/index.frag

Windows 10 x64 16299.64, Nvidia 388.31 WHQL

[hexaae]

It is also unstable and stops working randomly for me, if I don't use WineD3D DX wrapper. Here is a WinUAE crash log from Windows pointing to video drivers indeed:

Descrizione
Percorso dell'applicazione che ha generato l'errore: C:\Users\Luca\WinUAE\winuae.exe

Firma del problema
Nome evento problema: APPCRASH
Nome applicazione: winuae.exe
Versione applicazione: 3.6.0.0
Timestamp applicazione: 59f609fe
Nome modulo con errori: nvd3dum.dll
Versione modulo con errori: 23.21.13.8831
Timestamp modulo con errori: 5a0b421c
Codice eccezione: c0000005
Offset eccezione: 00646bd8
Versione SO: 10.0.16299.2.0.0.768.101
ID impostazioni locali: 1040
Informazioni aggiuntive 1: 2beb
Ulteriori informazioni 2: 2beba6fb4680d73a8c78ca7c24ccdb46
Ulteriori informazioni 3: 3ad0
Ulteriori informazioni 4: 3ad0e9f4486e91d86927e4a71227ee49

I suppose not many WinUAE users have set up a Picasso WB 3.9 desktop + separate native screens for (WHDLoad/installed) gaming (most users run AGA 3.9 WBs and use ADFs for games), so I'm the first to notice these kind of problems switching screens and returning back to WB without rebooting...
Maybe it's just Windows 10 FCU/Nvidia driver issue, because I can't remember these problems with WinUAE under Win10 AU.

Attached recent crashlogs.

[Toni Wilen]

As usual, JIT must be always, JIT makes dump files useless.

Also wait for next beta and check if new D3D11 mode has same problem.

[hexaae]

... Tested b8 (disabled HW sprites for RTG Picasso96 emu) with DX11 enabled, and still trashes audio and makes WinUAE unstable with NVidia 388.31 WHQL (with GeForce Experience installed) + Windows 10 x64 FCU 16299.64.

In DX9 mode using WineD3D DX9->OpenGL wrapper, my Amiga system becomes rock solid and have no crashes or trashed audio/video even after hours of testing with games (that can quit back to WB sys-friendly) and utilities.

[DamienD]

Logs provided then hexaae???

<nope>

Toni really can't do much without them... I know he has a very powerful crystal ball but still

[hexaae]

I need instructions from Toni. I'll be happy to provide logs but this is a tricky bug, not usual reproducible crash (with log) on triggered specific action.
I can reproduce 10/10 the trashed audio issue though, like in the video in msg #1... is there a way to log WinUAE run-time in this case?

[DamienD]

Does launching WinUAE, going to "Paths", ticking "Enable full logging", starting emulation and then running until the crash occurs not show anything in both logs?

[hexaae]

Originally Posted by DamienD

Does launching WinUAE, going to "Paths", ticking "Enable full logging", starting emulation and then running until the crash occurs not show anything in both logs?

Random crashes may not exactly point to the trashed audio + slowdown issue, so it can be useless and not point to the real problem since they happen without an apparent pattern in normal WB usage, but I will log them in case.
I'd like a way to monitor "what's happening to WinUAE ATM" when the slowdown + sound issues occurs instead, that I can always reproduce manually, contrary to the random crashes and instability problems...

[DamienD]

Hmmm, not at home so can't test.

Can't you run WinUAE with -log? This opens up a command prompt along with WinUAE and logs activity. You may need another switch too though in order to get greater details. Memory fading...

[Toni Wilen]

Logging won't help much, it is usually too late when weird messages appear in the log but you can try using -log command line parameter to see the log in real time. Crash dumps are useless unless it happens without JIT.

Does same happen if you use DirectDraw mode (don't use it in fullscreen, it probably gets really slow). DD still seems to work fine in windowed mode.

Anyway, sounds like some Windows or driver issue if wine wrapper "fixes" it.

[hexaae]

I've set DirectDraw, WB (Picasso96 emu Z3 1920x1080 32bit) in full-window, native resolutions in window. The slowdown and audio trashed after some screen switches still happened.

Yep, for me too it's just a Window 10 CFU + Nvidia driver issue at this point...

I'll go on with WineD3D wrapper in the meanwhile (stable workaround), waiting for next Windows and Nvidia updates and crossing finger at one point everything will work rock solid as before.

For any (good/bad) future news I'll drop a line here.

[hexaae]

@Toni
I still can't find a solution to this strange bug... What kind of logs or tools or output you need when I experience the slowdown bug? Is there something I can do to help you investigating?
I'm afraid MS and Nvidia will never fix it...

[Toni Wilen]

I have no idea. Narrowing it down probably is the only possible route: does it happen if you disable sound? does it still happen if you disable screen updates (press numlock)

Keep also task manager open (details page) with all the memory columns enabled and handles and keep looking that none of them isn't climbing slowly etc.. Also keep resource monitor open and watch total number of handles. It shouldn't keep increasing either.

It still sounds like some weird power saving/throttling issue.

EDIT: screen update short cut isn't default anymore, use "Toggle screen updates" input event. (and it was scrolllock, not numlock)

[hexaae]

Originally Posted by Toni Wilen

It still sounds like some weird power saving/throttling issue.

Yes, looks like after switching Picasso mode (fullscreen borderless) <-> native modes (fullscreen exclusive) multiple times, some internal WinUAE timings go crazy, also mouse movements are jittering, and the only solution is to quit and restart whole WinUAE (resetting and rebooting WB doesn't change a thing).
It's also quite strange that wrapping DX -> OGL with wined3d.dll workarounds the problem: video timing issues switching screens in the emulator with Nvidia drivers? I have g-sync btw
Will monitor as you suggest...

[hexaae]

Originally Posted by Toni Wilen

I have no idea. Narrowing it down probably is the only possible route: does it happen if you disable sound? does it still happen if you disable screen updates (press numlock)

... this is interesting:

1. disable screen updates won't work on Picasso IV WB screen (normal?)
2. when the emulation starts to crawl (zombie mode ), I switch to the native PAL 50Hz screen (please notice the music sounds trashed only on the WB screen in Picasso mode) and disable screen updates, then switch back to WB screen... it recovers from zombie mode! At this point I can re-enable screen updates for the native screen and everything will continue without slowdowns anymore...

[hexaae]

I was wrong, after a while the slowdown happened again and 2) did nothing...

Waiting 5-6 minutes more the speed auto-magically got back to normal!!
IMHO it's Windows 10 FCU that for unknown reasons dislikes WinUAE execution and degrades performance randomly altering emulated CPU/chipset speed and/or timing... or there's a bug in WinUAE in case of weird video configs (I use WB in full-window Picasso emu 1080p 60Hz, even though my desktop res is 75Hz, and for games native full-screen 50/60Hz silky smooth with g-sync)

The strange thing is that besides WinUAE I have never seen this issue with games from Steam etc.

Windows 10 x64 FCU 16299.125, Nvidia driver 388.71 WHQL, GeForce Experience 3.11.0.73
Gaming laptop ASUS G751JY
Chipset: Intel HM87 Lynx Point, CPU: i7-4860HQ, RAM: 24GB DDR3L 2133MHz, Gfx card: GTX 980M (GM204M, 10DE-1617/1043-22DA Rev A1, vBIOS v84.04.48.00.39), 4GB GDDR5 (Micron)], OS: Windows 10 x64, Screen: G-Sync LG Philips LP173WF4-SPD1 (LGD046C) 17", desktop res: 1080p 75Hz, Audio: Realtek, Controllers: Competition Pro USB arcade joystick SpeedLink SL-6603-SPORTS-EU, XBox One Bluetooth controller, Microsoft PN7-00004 Bluetooth mouse