WinUAE 2.4.0 beta series

[rsn8887]

First impression:

Wow! It looks like stuttering is (almost) fixed! I did get three very small glitches (like one frame lost/flickering) in slamtilt, during 3 minutes play, but it went back to smooth immediately after each glitch, instead of continuing to stuttering forever!

However, the screen tearing (unnoticeable in Slamtilt, but instantly noticeable on top of screen in Vision Megademo) is still there. In the loading and decrunching part, the first maybe 20 pixels of the top scroller show tearing. In the different parts of the demo, the tearing involves more or less pixels of the top of the screen. For example, in the part with the digitized faces on top, the tearing involves the top part of the big scroller, which is closer to the center of the screen. I didn't notice any of the glitching described above that I see in Slamtilt, apart from maybe the first part of the demo, after the first press space, where I think I saw some of that glitching (stuttering of one frame every once in a while).

Sitll testing 100 Hz Behringer Audio ASIO. Will have to test 60 Hz later. Triple buffering display mode still works perfectly!

I hope this helps.

[Toni Wilen]

Originally Posted by Ian

Understood.

How about changing the text of the button to "use built in CDFS" or something like that?

If you are planning to remove using CDs as windows drives it won't cause to much harm in the long run?

I'll think about it...

Originally Posted by rsn8887

First impression:

Wow! It looks like stuttering is (almost) fixed! I did get three very small glitches (like one frame lost/flickering) in slamtilt, during 3 minutes play, but it went back to smooth immediately after each glitch, instead of continuing to stuttering forever!

However, the screen tearing (unnoticeable in Slamtilt, but instantly noticeable on top of screen in Vision Megademo) is still there. In the loading and decrunching part, the first maybe 20 pixels of the top scroller show tearing. In the different parts of the demo, the tearing involves more or less pixels of the top of the screen. For example, in the part with the digitized faces on top, the tearing involves the top part of the big scroller, which is closer to the center of the screen. I didn't notice any of the glitching described above that I see in Slamtilt, apart from maybe the first part of the demo, after the first press space, where I think I saw some of that glitching (stuttering of one frame every once in a while).

Sitll testing 100 Hz Behringer Audio ASIO. Will have to test 60 Hz later. Triple buffering display mode still works perfectly!

I hope this helps.

Great! Getting there slowly but surely..

Tearing always happens if page flip gets delayed, unless it is buffered mode. I may be able to fix it in double buffered mode but no buffer simply requires very exact timing and may never work with all PCs..

I have an idea that may allow fastest possible/JIT vsync without secondary polling thread.. Testing needed..

Maybe it is also time to get rid of old vsync completely (if above works), low latency + triple buffer equals old vsync latency and it also works much better (normal vsync + jit = huge slowdown in emulated CPU speed)

[Mequa]

Amazing progress Toni! This would be VERY useful for running e.g. AMOS with AROS-68k ROM (JIT + fastest possible gives by far the best performance with that combo) with smooth scrolling...

Originally Posted by Toni Wilen

Maybe it is also time to get rid of old vsync completely (if above works)

Would you mind keeping it as an option (only perhaps less prominent)? For one thing, the old vsync doesn't crash Wine the same way the new one appears to.

[FrodeSolheim]

Originally Posted by Mequa

Would you mind keeping it as an option (only perhaps less prominent)? For one thing, the old vsync doesn't crash Wine the same way the new one appears to.

I second that As far as I can see, regular vsync is the best way to run amiga 500/1200 in cycle-exact mode with perfect scrolling (e.g. for running classic floppy games).

[rsn8887]

Did some more tests on Vision Megademo IV:
- Tearing only happens in A1200, fastest possible mode.
- Tearing is bigger (encompasses top third of screen) in double buffer display mode.
- No tearing in "Approx. A500/A1200" mode, with or without cycle exact.
- Looks like there's no tearing, in any mode, on the emulated A500

- Unimportant side note: Sad but true - looks like my computer is too slow to run first part (after press space) of Vision Megademo IV in A500 cycle exaxt mode (CPU % 140)! Well, there's lots going on there, and it works just fine w/o cycle exact, so I don't really care.

- This is the most stable WinUAE release in terms of smoothness and sound ever! Great work Toni!

- I still have to select "swap both" to get the right sound channel assignment on the emulated A1200, btw. Tested with poing.

- Tearing still there in 60Hz NTSC mode. Vision Megademo IV does not like 60 Hz, it runs sloow, but tearing is nevertheless visible in third part.

[Toni Wilen]

One more tweak: http://www.winuae.net/files/b/winuae.zip

Now only "no buffer" mode tries to reduce latency as much as possible (requires more cpu power, exact page flipping timing etc.. or there will be tearing)

Double and triple buffered lets the display driver to time the page flip normally (automatically flip when next vblank, adds one frame worth of latency), also does not busy wait. This mode should now always work better than old vsync.

Originally Posted by rsn8887

- Unimportant side note: Sad but true - looks like my computer is too slow to run first part (after press space) of Vision Megademo IV in A500 cycle exaxt mode (CPU % 140)! Well, there's lots going on there, and it works just fine w/o cycle exact, so I don't really care.

Do you mean when not using vsync? It isn't that chipset heavy, lots of moving stuff but nothing special.

[rsn8887]

Originally Posted by Toni Wilen

One more tweak: http://www.winuae.net/files/b/winuae.zip

Now only "no buffer" mode tries to reduce latency as much as possible (requires more cpu power, exact page flipping timing etc.. or there will be tearing)

Did you make any change to "no buffer" mode? Looks like screen tearing is gone here!!! Tested with 100Hz, Vision Megademo IV.

I posted random snippets before. Edited them out. Here is the bottom line:

I saw tearing once in no buffer mode, but couldn't reproduce it so far. Otherwise no buffer mode seems to work fine. Has impact on speed though. Could it be that the speed impact of no buffer mode in this version is larger than that of triple buffer mode in last version? I see it on my emulated A1200 in fastest possible. It seems slower than on last version's triple buffer mode. I also see this on Leander in A500 mode "approximate A500 Speed." Triple buffer last version: 80% CPU. No buffer this version: 100+% CPU in Leander.

All tested in 100Hz no latency vsync modes.

Dual buffer and triple buffer both stutter and glitch now, takes a few seconds to start, and sometimes goes away by itself after a few seconds. Can also be made to go away by switching buffering modes. But comes back after a while. Tested with Vision Megademo IV on A1200 fastest possible. Also saw something similar in Hyperdrive. Stuttering seems most likely to happen after mouse click in part one of the demo, after part one ran for a while (20 seconds or so). But also last part of demo stutters almost always. This is with no sound buffer underruns.

Originally Posted by Toni Wilen

Do you mean when not using vsync? It isn't that chipset heavy, lots of moving stuff but nothing special.

No, I was testing with cycle exact+low latency Vsync.

[Toni Wilen]

"No buffer" vsync requires more power, it is designed to do that for lowest possible latency.

Anyway, yet another attempt: http://www.winuae.net/files/b/winuae.zip

Double and triple buffering hopefully works properly again..

[Mad-Matt]

Im not sure if this low latency stuff is ment for RTG modes (but the options do exist), but theres seems to be an issue since beta5 (upto beta4 has been fine) where the rtg screen doesnt appear to open properly or emulation is stalled when using low latency vsync.

Sometimes it will stall a few seconds after wb has booted. If normal vsync is selected then the emulation continues on as normal. pretty minor glitch really and easily avoided at the moment if its not ment to work yet.

[msayed1977]

tested your latest update.
winuae crashes.
tried 2 different games.(Kick Off 2, Battle Chess).
here is my configuration attached.(Mohammed Sayed.uae).

[Toni Wilen]

winuae.zip test versions are only meant for specific test cases, which is low latency vsync + fastest possible CPU in this case.

EDIT: if this is from official b5, attach also crash dump.

EDIT2: Mad-Matt, it isn't officially supported yet, wait until it is listed in changelogs

[rsn8887]

Originally Posted by Toni Wilen

"No buffer" vsync requires more power, it is designed to do that for lowest possible latency.

Anyway, yet another attempt: http://www.winuae.net/files/b/winuae.zip

Double and triple buffering hopefully works properly again..

The potential of having perfectly smooth emulated Amiga without ANY glitches or stutters in scrolling is just too great!

But, damn, I am getting stutters still. In all buffering modes actually. It is best tested with Vision MegaDemo IV, last part. The central horizontal small text scroller. It starts stuttering after about 1 minute. Switch from dual buffer to triple buffer or vice versa, and stuttering goes away, only to come back after a minute or two. Seems a bit less severe without sound, but even with disabled sound, I still see noticeable hickups in scrolling. I made a savestate to test it faster (I know, shouldn't do that), but it is also there by just clicking through the demo, e.g. it is not an artefact of savestate.

Re-tested with beta from Dec. 18th, and triple buffer works perfect there. However, now testing more closely, I do observe a similar stutter in no buffering and dual buffering (+some tearing that was typical to that beta) on this part of the MegaDemo. I guess I never tested no buffering on that beta that well, because triple buffering worked so well.

There must have been something really special about the low latency triple buffer mode that was in the beta from Dec. 18th (the last busy wait beta, before you switched back to OS buffer flipping). It is the only mode that works absolutely perfect for me. (I cannot get it to stutter ever, and no tearing). Needless to say, I really like that beta

In fact, the latest beta behaves a lot like "old" winUAE vsync on my system, in the behaviour of the stuttering. With old vsync, I would also get perfectly nice scrolling sometimes for a long time, like 1 min or longer sometimes. But suddenly it would show a hickup or two, and from then on more hickups and, while pretty nice, it just wasn't ever absolutely perfectly glitch free. Not like the beta from 18th December in triple buffering is for me now. I started observing the glitching in old vsync versions of WinUAE, on a different older computer, and I also read a few posts of people saying that WinUAE cannot ever be perfectly smooth in this forum. This makes me believe that it was not just only my system either. Maybe OS buffer flipping is just sucky?

All tested using 100Hz A1200 fastest possible low latency vsync

[Toni Wilen]

Originally Posted by rsn8887

Damn, I am getting stutters still. In all buffering modes actually. It is best tested with Vision MegaDemo IV, last part. The central horizontal small text scroller. It starts stuttering after about 1 minute. Switch from dual buffer to triple buffer or vice versa, and stuttering goes away, only to come back after a minute or two. Seems a bit less severe without sound, but still noticeable hickups in scrolling even without sound. I made a savestate to test it faster, but it is also there by just clicking through the demo, e.g. it is not an artefact of savestate.

Re-tested with beta from Dec. 18th, and triple buffer works perfect there. However, now testing more closely, I do observe the same stutter in no buffering and dual buffering (+some tearing) on this part of the MegaDemo.

There must have been something really special about the low latency triple buffer mode that was in the beta from Dec. 18th (the last busy wait beta, before you switched back to OS buffer flipping). It is the only mode that works absolutely perfect for me. (I cannot get it to stutter ever, and no tearing)

Maybe OS buffer flipping is just sucky?

All tested using 100Hz A1200 fastest possible low latenvy vsync

It isn't vsync problem if you only see stutters in one demo part, this is more likely issue with demo + fastest possible CPU mode. (At least here this part gets totally messed up if JIT is enabled).

I got one similar "problem", originally I used Great Gianna Sisters title screen scroller as a vsync test (in fastest cpu mode) and I wasted time to debug random stutters until I noticed it is not vsync problem, just a compatibility problem with fastest possible mode..

[Dr.Venom]

Originally Posted by Toni Wilen

winuae.zip test versions are only meant for specific test cases, which is low latency vsync + fastest possible CPU in this case.

Working well here. There are two or three instances in fastest possible and running heavy aga demos where shortly the sound gave a few pops and clicks (led at -99 and flashing red), but generally working very well. A500 cycle exact runs without any issues..

Some questions/remarks:

• What happened with the "exclusive" mode/option for wasapi? Is it now automatically exclusive, or..?
• Why is the buffer size at setting 1 and 2 "(1323)" samples and not 1024? I would expect 1024 as all other settings (3 to 7) seem to be [BUF=XXX * 8]. WASAPI: EX=0 CH=2 FREQ=44100 BUF=64 (1323)
• This is probably because it's a beta, but the "Frequency" runs at 44100, even when 48000 is selected...

Furthermore, I like that you added the volume slider

Originally Posted by rsn8887

Damn, I am getting stutters still. In all buffering modes actually. It is best tested with Vision MegaDemo IV, last part. The central horizontal small text scroller. It starts stuttering after about 1 minute. Switch from dual buffer to triple buffer or vice versa, and stuttering goes away, only to come back after a minute or two. Seems a bit less severe without sound, but still noticeable hickups in scrolling even without sound. I made a savestate to test it faster, but it is also there by just clicking through the demo, e.g. it is not an artefact of savestate.

Re-tested with beta from Dec. 18th, and triple buffer works perfect there. However, now testing more closely, I do observe the same stutter in no buffering and dual buffering (+some tearing) on this part of the MegaDemo.

There must have been something really special about the low latency triple buffer mode that was in the beta from Dec. 18th (the last busy wait beta, before you switched back to OS buffer flipping). It is the only mode that works absolutely perfect for me. (I cannot get it to stutter ever, and no tearing)

Maybe OS buffer flipping is just sucky?

All tested using 100Hz A1200 fastest possible low latenvy vsync

Are you by any chance running Windows Vista or Windows 7? If so are you running with Aero / Desktop Composition enabled or disabled?

[rsn8887]

Originally Posted by Toni Wilen

It isn't vsync problem if you only see stutters in one demo part, this is more likely issue with demo + fastest possible CPU mode. (At least here this part gets totally messed up if JIT is enabled).

I got one similar "problem", originally I used Great Gianna Sisters title screen scroller as a vsync test (in fastest cpu mode) and I wasted time to debug random stutters until I noticed it is not vsync problem, just a compatibility problem with fastest possible mode..

Correct! Unbelievable. I just tested 21st Dec. beta with Hyperdrive: absolutely NO glitching/stuttering or tearing in no buffer (this is a first) OR triple buffer. A lot of glitching/stuttering in dual buffer. Need to do more tests with different programs, I suppose.

EDIT: Never mind. All modes look perfect now, as long as I don't switch between them "on the fly". I think my observation of stuttering in dual buffer is due to this weird, but minor thing: It looks like at least Hyperdrive (didn't test other programs) behaves like the following: If I boot the emulated Amiga in double buffer mode. There is no stuttering, perfectly smooth. When I switch on the fly to triple buffer, while playing the game, there's lots of stuttering. When I switch back to double buffer, still stuttering. When I now switch to no buffer - perfectly smooth. When I switch back to double or triple buffer, still stuttering. A soft boot (amiga amiga ctrl) of amiga fixed this, when I reload the game, there's no sign stuttering again. The whole sequence can then be repeated with same results. Is this normal?

[Toni Wilen]

First, winuae.zip updated again. This solves random really strange effects where D3D gets totally confused and either hangs or stops updating or keeps showing last 2 previous frames forever or something else..

D3DCREATE_MULTITHREADED flag must be of course set because Present() (flip buffers) call is done from another thread..

Oops..

[*] What happened with the "exclusive" mode/option for wasapi? Is it now automatically exclusive, or..?

Check the sound device selection list more carefully

[*]Why is the buffer size at setting 1 and 2 "(1323)" samples and not 1024? I would expect 1024 as all other settings (3 to 7) seem to be [BUF=XXX * 8]. WASAPI: EX=0 CH=2 FREQ=44100 BUF=64 (1323)

I assume WASAPI does not accept smaller buffers and it gets set to smallest acceptable.

[*] This is probably because it's a beta, but the "Frequency" runs at 44100, even when 48000 is selected...

AFAIK WASAPI, at least some drivers, only accept "native" sound card rate(s).

Are you by any chance running Windows Vista or Windows 7? If so are you running with Aero / Desktop Composition enabled or disabled?

Now I have 100% smooth scrolling even on windowed mode + aero enabled (win7). Previously for some reason it did only work if aero was disabled. Perhaps it is driver difference (now I have Catalyst 12.1 "preview" drivers installed)

The whole sequence can then be repeated with same results. Is this normal?

Perhaps, no idea why it happens yet.. Or perhaps it is due to missing D3DCREATE_MULTITHREADED flag? (see above)

[msayed1977]

here is my dump file.

[Dr.Venom]

Originally Posted by Toni Wilen

Check the sound device selection list more carefully

Ah, OK

I assume WASAPI does not accept smaller buffers and it gets set to smallest acceptable.

I'm not sure. 1323/44100 equals a buffer of 30ms, which seems a bit large as being the smallest buffer?

In the process I also stumbled upon a difference between normal wasapi and exclusive wasapi. They use different buffer sizes at same settings 1-7, which seems strange?

E.g. exclusive's lowest settings of 1 equals the buffer/latency setting of 4 in non-exclusive (exclusive is also noticably laggier than normal wasapi when both set to 4). This is on an Asus Xonar DX PCI-E soundcard btw.

Below the exact numbers as reported by the winuae log:

Sound
Buffer
Size    Normal Wasapi       Exclusive Wasapi
  1     BUF=64 (1323)       BUF=64 (4096)
  2     BUF=128 (1323)      BUF=128 (8192)
  3     BUF=256 (2048)      BUF=256 (16384)
  4     BUF=512 (4096)      BUF=512 (32768)
  5     BUF=1024 (8192)     BUF=1024 (65536)
  6     BUF=2048 (16384)    BUF=2048 (131072)
  7     BUF=4096 (32768)    "Sorry, can't initialize sound"

AFAIK WASAPI, at least some drivers, only accept "native" sound card rate(s).

It doesn't seem to be the case here. Non-exclusive always logs as 44100 whatever the setting, but exclusive does log that it accepts 44100, 48000 and even 96000 (when entered manually in the box..) Any idea?

Now I have 100% smooth scrolling even on windowed mode + aero enabled (win7). Previously for some reason it did only work if aero was disabled. Perhaps it is driver difference (now I have Catalyst 12.1 "preview" drivers installed)

Sounds cool. I still need to test windowed mode with the new betas. Will let you know..

[Toni Wilen]

Originally Posted by Dr.Venom

Ah, OK

I'm not sure. 1323/44100 equals a buffer of 30ms, which seems a bit large as being the smallest buffer?

In the process I also stumbled upon a difference between normal wasapi and exclusive wasapi. They use different buffer sizes at same settings 1-7, which seems strange?

I get exact same buffer sizes (exclusive vs non-exclusive), even when size=1. It is sound card/driver specific (Auzen X-Fi Forte here), buffer size you requested may not be what you get.

Non-exclusive always logs as 44100 whatever the setting, but exclusive does log that it accepts 44100, 48000 and even 96000 (when entered manually in the box..) Any idea?

I remembered now

Non-exclusive mode is same as device's Windows Sound panel "Default Format" setting. Exclusive can be anything as long as hardware directly supports it.

[Toni Wilen]

Originally Posted by msayed1977

here is my dump file.

This is not from official b5 (winuae_2400b5.zip). Only dumps from official betas (and final versions) can be used for debugging.