Interlaced frame type mismatch

[Dr.Venom]

Hi Toni,

Still enjoying the hell out of WinUAE, as always

There still an issue which I hope you can fix. We talked about it in 3.4.0. series, but unfortunately never got solved.

It's about the Interlaced frame type mismatch behaviour in real interlaced modes. Please see attached log from testing on Windows 10 x64 Creators update. It does the following:

51-733 [3468 000-000]: Interlaced frame type mismatch 1<>0 (-1,616)
51-854 [3474 000-000]: Interlaced frame type mismatch 1<>0 (-1,-1)
51-953 [3478 000-000]: Interlaced frame type mismatch 1<>0 (-1,617)
52-074 [3484 000-000]: Interlaced frame type mismatch 1<>0 (-1,-1)
52-173 [3488 000-000]: Interlaced frame type mismatch 1<>0 (-1,616)
52-294 [3494 000-000]: Interlaced frame type mismatch 1<>0 (-1,-1)
52-393 [3498 000-000]: Interlaced frame type mismatch 1<>0 (-1,617)

It seems the mismatch is alternating on the last and first line of every other field, which may be suggesting that both WinUAE -and- Windows or video driver are trying to match correct field?

The interlaced frame type mismatch happens on a series of video cards, tested in Windows 10 (both older and newer AMD and NVidia cards).

Other than that more testing seems to suggest that the issue starts occuring with WinUAE 3.4.0 beta 1, the first beta version with Wasapi pull mode.

Here is additionally the post from the 3.4.0 thread describing the same issue (dismiss the beta 5/6 comments, as current testing shows differently). It also holds a sample config for easy testing on LCD (I'm mostly using CRT):

http://eab.abime.net/showpost.php?p=...&postcount=342

As said there seems a (small?) chance that interlaced behaviour has changed in Windows 10 DirectX and/or video drivers, which guarantees correct field type behaviour already?

If that may be the case, could you possibly make a config option to disable the frame type matching in WinUAE?

[Toni Wilen]

Does it cause any visible problems? (Except log spam..)

[Dr.Venom]

Originally Posted by Toni Wilen

Does it cause any visible problems? (Except log spam..)

As far as I can see it does not cause any visible problems.

Edit: The problem is that is causes audio issues (cracks / pops) when the frame type mismatch is happening.

Edit 2: In interlace scenes with scrolling / moving parts the video gets visibly choppy also (see for example interlace parts with big scroller in Big Time Sensuality).

[Dr.Venom]

I did some further testing and only -very occasionally- the problem does not occur, very strange. I can't reproduce it in any way, it seems to happen randomly that the issue does not occur.

Not sure if you saw my previous post edit, but the problem is that audio gets interrupted when frame type mismatch happens. Additionally in moving interlaced parts (like the mentioned big scroller in demo Big Time Sensuality) there's stuttering.

Just let me know if I can do anything else for testing.

[Toni Wilen]

Right, it was that old problem.. If I remember correctly, reason is pull mode sound which causes sort of lock-sync state where sound timing forces the vsync polling code to not run when emulation is waiting for next pull event.

Not sure if there are any easy fixes..

[Dr.Venom]

Originally Posted by Toni Wilen

Right, it was that old problem.. If I remember correctly, reason is pull mode sound which causes sort of lock-sync state where sound timing forces the vsync polling code to not run when emulation is waiting for next pull event.

Not sure if there are any easy fixes..

Ah that explains it also only happening in Wasapi pull mode. Can you think of any possible solution? It was all working so well it would be sad to lose the proper interlace feature when using Wasapi..

If there are no real fixes given current implementation, could you possibly add a config option to disable the interlace frame type matching? At least if that would solve the audio problems interlace mode it would be better than how it is now.