Yes. Also you should already know that "Quick questions" are not acceptable. EDIT: at least include if 4.4 works, did it ever work in any beta. D3D9 or D3D11. No weird filters enabled at same time and so on.. At least some background information that allows me to answer something better than "Yes/No" and "not enough information" (or variant of it).

Sorry Toni, I shall hunt out a crystal ball and hit myself in the head with it :)

https://download.abime.net/winuae/files/b/winuae.7z now has part of b9 change reverted. Does it appear to work better?

Yes, thank you Toni.

I no longer have crackles / pops with "Aladdin [AGA]" intro and also "Alien Storm" carcktro / trainer are fine; like with v4.4.0 ;-)

So it is not possible to have both, the stable frame rate and the sound w/o cracks & pops?
Now again the frame rate jumps between 48.x & 51.x! Before was stable at 49.9 all the time.

EDIT: Yea, the framerate with DSOUND is much stable than with WASAPI and when you add there's no more cracks and pops, I would say its better than before! :)

Did you manage to look at the Quake II RTG mode Toni? And do you require the HDF? Thanks ;-)

Im not very clued up on this matter, but both MAME and VICE also oscillate between those values. This has been fixed with GroovyMame I think, or at least it is supposed to fix inaccuracies on CRT displays. Games were never meant to be played at a fixed FPS, as there were no digital (LCD) screens in the 1990s. So when you play them today on a fixed Hz display, you get sound sync errors. The Paula chip is analogue, and the Denise chip is also analogue, and meant for analogue (CRT) displays. V-sync is a way to inaccurately fudge the output to match a fixed display Hz on a modern screen, but at the expense of audio sync, hence the clipping.

So which one do you want, an exact analogue display with matching audio timings, at 49-51 fps, or an inauthentic digital display at 49.9Hz, and bad sound?

No. Yes :)

49.92Hz is correct value (or 50.00 if interlace or 50.08 if short field) and it is 100% stable in real world.

Yes, it is much better to let frame rate change slightly than have audio glitches. Almost no one would notice without OSD anyway.. (and note that vsync uses different method that can introduce more sound glitches because it has to sync with video)

There are better ways to do this but it is not in next version and it most likely require changes that are not compatible with dsound anymore.

Haha ;-) PM sent Toni

Agree. Also from my experience DSOUND gives much better fps smoothness without micro-lags/hiccups (e.g. for testing: Shadow of the Beast 1 main menu with never ending scrolling).
With b33 switching from WASAPI to DSOUND 99.99% eliminates small random hiccups in the scrolling...
I use display > fullscreen (with VSync options EMPTY!) for native resolutions and I have a g-sync display.

I opened a thread long time ago about sound sync issues: http://eab.abime.net/showthread.php?t=104310

https://download.abime.net/winuae/fi...uae_4900b34.7z
https://download.abime.net/winuae/fi...e64_4900b34.7z

Beta 34:

- Harmnless bug causing "Negative nr_color_changes.. " log messages fixed.
- Copper VBLANK startup was 2 cycles too early. (Previous fix was not correct)
- Partially reverted b9 sound update that caused worse sound stability on some systems. It also makes FPS value slightly less stable.
- Audio volume (from AUDxVOL) is only loaded to internal volume register when period counter is loaded. Volume changes during period counting don't affect audio until next period load.
- Copper writes to AUDxDAT in non-cycle exact modes had inaccurate timing.
- AUDxDAT undocumented feature: AUDxDAT write has 1 cycle delay, state machine==3 INTREQ test is done when period counter==1, not when it is zero. (Thanks to ross again, another weird test set :))
- RTG screen was not fully cleared in some situations when switching modes (b25)
- Changed debugger "dp" to "dppc" (switch to PPC disassembly mode)
- Ateo Pixel 64 RTG board emulation. Another Cirrus Logic based RTG board. Very quickly done, only works with recent Picasso96 versions, does not work with drivers that need ateobus.library (will be done if someone disassembles it, I am too lazy, as usual). 256 color mode has wrong colors and right edge wraps around. Does not autoswitch.
- "Smooth Copper" works correctly again.

Something is broken (even before b34) with display > Windowed: Filter with mask seems applied twice here in DX11, and even if Filter: Masks=none... Moreover there's a sort of strange bad buffering where I can see 2 frames constantly swapped (hard to explain)...
This happens in Windowed mode only.
https://i.ibb.co/yR6QcS1/image.png


EDIT: mmmh, seems more complicated to reproduce: only happens when you switch from Native Fullscreen to Native Windowed
EDIT2: from my early testings it started with b32

Formula 1 Grand Prix - The game get stuck at track 43! (again) :)

"Smooth Copper" hack works fully correct now with 68000! (or its not a hack anymore?! no way) :D


The frame time seems to be more uniform with DSOUND that small random hiccups seems less noticeable I guess.

Can't duplicate (I noticed that other thread but posting beta specific there isn't good idea). Also not enough information: exact image is always required.


It still a hack because I don't wan to make it too generic implementation yet, lots of things can break pointlessly.

Formula 1 Grand Prix.adf (CRC=3E1E6A69)(EDIT: Look in "The Zone!")!deleted after confirmation!

Quickstart A500 1.2 OCS 512 configuration.

EDIT: Fine in b31! (Btw. I always use 32-bit versions for testing!)

The strange thing is I noticed in the above mentioned thread that it all started with >=3.4.0b1. Up to 3.3.0 public, WASAPI was as smooth without stuttering and audio cracklings as DSOUND... (but this is off-topic here, let's talk about this problem in the other thread)

This is most likely caused by remaining problem, 68000 interrupt (IPL) pins sampling timing. Until it is exactly right, something will always break. (two or more wrongs can make it right in emulation)

I'll try to adjust this a bit that hopefully mostly fixes this (and Spectreparty demo which has same problem) but this can't be perfect until CPU interrupt timing is 100% perfect (t won't happen in this version).

So yeah, next week is an anniversary so it’s time for the final version, I guess!

Btw. Does this mean that there are still some unknown timing issues regarding the CPU? (or just IPL sampling)
EDIT: I have already found the answer here. (The message is: don't assume, always bother to check.) :D

Ps. Ok, same happens also with 4400, so no big deal. :)

This is getting more, lets say, interesting. 68000 interrupt start up processing counted interrupt vector fetch cycle twice (extra 4 CPU clocks) and after fixing it, spectreparty demo flickers 10x+ more :)

Which means it can't be simple IPL sampling issue anymore. Need to debug this more..

Some 68000 IPL timing updates added. Spectreparty does not flicker anymore and it does not seem to break anything else.

"Formula 1 Grand Prix (1988)(MicroValue)" also does not hang anymore. But oddly enough game menu's reaallllyy ssssslluggissh behavior is A500 confirmed. It polls for interrupt badly and I thought it was related to bad IPL timing in emulation.. That can't be what it was designed to do, perhaps it requires something unexpected..

I'll clean up the fix first before next official beta.