RawInput enumeration after "on the fly " screenswitch causing audio/video hickup

[Dr.Venom]

I'm running into an issue where the sound / video has a noticable glitch/hickup after a "on the fly" screenswitch (configured with displaydata).

Looking deeper into it, the cause seems to be a full rawinput device enumeration occuring after each screenswitch. So screenswitch finishes and a fraction of a second later full rawinput enumeration gets logged at the same time the audio/video hickup occurs.

I tried to create a "simple" testcase which you can replicate on LED display, using 1080p / 1080i on the fly switching, tested with both NVidia and iGPU.

Displaydata:
displaydata=50.000000,t=lof,pal,nlace,cmd=gfx_width_fullscreen=1920,gfx_height_fullscreen=1080,gfx_linemode=double,gfx_refreshrate=50,gfx_interlace=false,gfx_display=1
displaydata=25.000000,pal,lace,cmd=gfx_width_fullscreen=1920,gfx_height_fullscreen=1080,gfx_linemode=double2,gfx_refreshrate=25,gfx_interlace=true,gfx_display=1

I've been testing with the demo "Big Time Sensuality" from Axis, as it does a series of progressive/lace switchings during the beginning of the demo.

There's an interesting difference between using iGPU or NVidia, and additionally for iGPU a difference between version 3.0.0 and 3.1.0 onwards.

iGPU with WinUAE 3.4.0.b17
after -every- screenswitch a full rawinput enumeration occurs:

46-777 [101 000-000]: RawInput enumeration..
46-777 [101 000-000]: RAWINPUT: found 11 devices
[snip long list of devices..]


Nvidia with 3.4.0.b17
When using NVidia card both the audio/video hickup and the rawinput enumeration after a screenswitch do -not- occur.

iGPU with WinUAE v3.0.0 and 3.1.0 onwards
For the iGPU the issue does not occur in version 3.0.0. It starts occuring from 3.1.0 onwards.

Please see attached logs. Since this device enumeration on iGPU seems to be the cause for the audio video glitch/hickup after each switch, hopefully there a solution for it (or possibly the 3.0.0 behaviour re-enabled).

[Toni Wilen]

I have noticed mysterious change events even when nothing seems to change, I guess Windows 10 (or updates) added more events or something.

Unfortunately handling them by type is much more complex, it may be bit too late to rewrite it for 3.4..

[Dr.Venom]

Originally Posted by Toni Wilen

I have noticed mysterious change events even when nothing seems to change, I guess Windows 10 (or updates) added more events or something.

It does seem Windows 10 (and updates) has quite some changes going on under the hood. I guess the road to the Universal Windows Platform isn't without some bumps..

Slightly OT, but after running into the unfamous issue with forced vsync=on for the whole system, causing mysterious stutters in various games/apps, and the inability to turn vsync off even when the setting said "off", it has prompted me to force Windows 10 to not automatically install updates anymore*, such that I at least can keep a simple log and perform some checks that nothing is really broken after an update.

Unfortunately handling them by type is much more complex, it may be bit too late to rewrite it for 3.4..

I guess the most important thing would be that there's at least a solution in the end, whether that be 3.4 or 3.5 would be of secondary importance. (But if you're on the fence about it, 3.4 has my vote )

In any case just let me know if/when I can do any testing..



* For anyone interested: http://www.windowscentral.com/how-sc...tes-windows-10

[Toni Wilen]

Insider builds are more fun

Perhaps this is easier update than I thought, does winuae.7z stop detecting non-input related events? (and hopefully input change events still work..)

[Dr.Venom]

Originally Posted by Toni Wilen

Insider builds are more fun

Perhaps this is easier update than I thought, does winuae.7z stop detecting non-input related events? (and hopefully input change events still work..)

Awesome, works like a charm now! Thx!