WinUAE 2.4.0 beta series

[msayed1977]

Originally Posted by Toni Wilen

Yes, I noticed your config file but it works fine here.

Answers still needed:
Does it crash if you switch to windowed mode first?
Does it crash if you select "null filter" first?

It still crashes if I switch to windowed mode first.
BUT: It works fine if I select "Null Filter" instead of "none" filter.

[Mclane]

Hi Toni,

Will you be doing away with the old Vysnc totally as its missing in the latest Beta build?

I only ask as the new sync method works really nicely on my P4 but only if I set it to my PC refresh rate, as I have only 60 and 75 I set it to 60 but as a PAL user it all sounds so fast. With the older Vysnc I could limit it to 50 under the software and the Vsync worked fine, ok it was an emulated vysnc but It was ok to watch and no crackle like I get now if I limit to 50.

As you see its not a moan and yes I know I need a wondrous new PC but in my financial state that simply isn't going to happen any time soon, as it is the PC I have is a hand me down from a friend.

If I have to either HAVE to use a non synced software generated 50hz screen or a 60Hz synced screen then fine but think of the poor please

[Toni Wilen]

Originally Posted by Mclane

I only ask as the new sync method works really nicely on my P4 but only if I set it to my PC refresh rate, as I have only 60 and 75 I set it to 60 but as a PAL user it all sounds so fast. With the older Vysnc I could limit it to 50 under the software and the Vsync worked fine, ok it was an emulated vysnc but It was ok to watch and no crackle like I get now if I limit to 50.

I am not sure what were you doing because you don't and can't have vsync without matching refresh rate. It simply won't work. Vsync means by definition syncing to display refresh rate.

It would be same as using normal non-vsync mode with at least double buffering enabled.

[Mclane]

Pass Toni,
I used to tick the FPS adjust at 50 and choose Vsync in the native Windowed settings, it gave me a 50fps and I didn't see any tearing. If I just don't choose either of the new vsync options and tick the 50fps box its tearing all over the place.

Whatever the old Vsync did it seemed to work for me doing it that way..

If I do that now I get 50fps but the sound is awful crackling...

[Toni Wilen]

Originally Posted by Mclane

I used to tick the FPS adjust at 50 and choose Vsync in the native Windowed settings, it gave me a 50fps and I didn't see any tearing.

Right, that was only accidental "feature" because old vsync never supported windowed mode, it did nothing except changed buffering mode that prevented tearing.. (Guess what would have happened if old vsync would have gained windowed mode support in future?)

For some reason windowed mode was always set to "flip immediate" mode (even if buffering is double or triple) which can cause tearing. Apparently it is driver/pc/something specific because I didn't see any tearing.

It still crashes if I switch to windowed mode first.
BUT: It works fine if I select "Null Filter" instead of "none" filter.

This should be fixed.

http://www.winuae.net/files/b/winuae.zip

[msayed1977]

No, the crash still happens.

[Mclane]

Not here Toni re the crash..

If there's no filter used its an instant crash, turn on Null and its ok.

I found this out by accident after deleting the registry key and the default cfg.

It scanned the roms, gave me the beta warning and then if I chose a disk it just died..

Just re downloaded the winuae.zip in case I had a cached one..

Same issue..

[Toni Wilen]

Crash fix attempt n+1. Redownload winuae.zip and test, please.

[msayed1977]

Originally Posted by Toni Wilen

Crash fix attempt n+1. Redownload winuae.zip and test, please.

Crash still happens. Try again.

[Kettenhund]

i'm having the same problem. winuae crashes right after starting any disk.

[Toni Wilen]

Perhaps it is fixed now (make sure exe date is 24.12)

[Kettenhund]

for me it is.

[Mclane]

Sorry for the late reply, Yes its fixed now Toni, thanks...

[Dr.Venom]

Originally Posted by Toni Wilen

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.

Based on this it seems the Asus card is somewhat inferior. I remembered that the change in buffer outcome occured when I've exchanged my X-FI card for the Asus card. It's a bit disappointing that the Asus card is inferior to the X-FI built cards... But anyway, I've put my X-FI card (Auzen also) back in, and...

The new sound code (latest 24/12 beta) is impressive... It manages to run A500 cycle exact at wasapi exclusive setting 1 (a buffer of 1024 samples on the X-FI card, as logged!), meaning audio latency of ~20ms while keeping the buffer relatively stable! With 2.3.3 it didn't achieve that low latency without constant clicks and plops... I say

In A1200 fastest possible mode it has somehwat less stability, in the sense that at the very first start of WHDLoad games (from RTG workbench), it starves the buffer (red flashing led) resulting in crackling sound...After a few seconds it stabilizes and then manages to run WHDLoad games quite stable. Running AGA demos pronounces the effect of less stability/underruns on the other hand. This even at soundbuffer setting 4 (4096). Mainly tested with Big Time sensuality which wouldn't have problems in some of the earlier beta's.

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.

Makes sense now

A last question on the sound buffer settings. Both setting 1 and 2 result in the same buffer size, i.e. 1024 samples, and thus the same latency? Setting 1 uses buffer blocks of 64 frames and setting 2 of 128 frames per block. So it seems you're requesting a buffer of 16 blocks of 64 frames at setting 1 and 8 blocks of 128 frames at setting 2. Given this, is either setting 1 or 2 to be prefererred, giving how the synchronization / new sound code works? Intuitively I would say more blocks of finer granularity (setting 1 in this case) will be preferred?

[msayed1977]

the crash is fixed now. sorry for replying late.

[Toni Wilen]

Originally Posted by Dr.Venom

In A1200 fastest possible mode it has somehwat less stability, in the sense that at the very first start of WHDLoad games (from RTG workbench), it starves the buffer (red flashing led) resulting in crackling sound...After a few seconds it stabilizes and then manages to run WHDLoad games quite stable. Running AGA demos pronounces the effect of less stability/underruns on the other hand. This even at soundbuffer setting 4 (4096). Mainly tested with Big Time sensuality which wouldn't have problems in some of the earlier beta's.

Only in vsync (all buffer modes too?) or also in non-vsync modes?

A last question on the sound buffer settings. Both setting 1 and 2 result in the same buffer size, i.e. 1024 samples, and thus the same latency? Setting 1 uses buffer blocks of 64 frames and setting 2 of 128 frames per block. So it seems you're requesting a buffer of 16 blocks of 64 frames at setting 1 and 8 blocks of 128 frames at setting 2. Given this, is either setting 1 or 2 to be prefererred, giving how the synchronization / new sound code works? Intuitively I would say more blocks of finer granularity (setting 1 in this case) will be preferred?

I need to check what those values actually mean first

EDIT: I am adding support for XAudio2. It is MS's "official" replacement for DirectSound but not sure if it is only targed for games (not so low latency).

[Dr.Venom]

Originally Posted by Toni Wilen

Only in vsync (all buffer modes too?) or also in non-vsync modes?

Yes, it seems to happen in all vsync buffer modes and in non-vsync modes, but strangely not always with double and triple buffer (in no-buffer sync the sound buffer always starts in the red/crackling).

The weird thing is that in double and triple buffer I also get random slowdowns. So for example booting RTG workbench takes longer during the part where it's in native mode (when using double and triple buffer mode). About 4-5 times longer, rough estimate. Or loading a table in Slamtilt, the "loading" screen takes about 4-5 times the normal time. This happened several times (after fully quitting and restarting WinUAE). These slowdowns don't occur in no-buffering vsync. Also I had a few times where the Slamtilt intro, skipped parts by itself, and in a few seconds skipped to the menu screen. I don't know if it's related, but there were some instances, where the log stated "DSK: FIFO overflow!". Happened a few times, but I can't reproduce it consistently..

EDIT: Before pushing "submit reply", I thought I'd test changing the filter settings from "none" to "null filter" (as it was reported earlier as being a troublemaker) and this completely removes the random slowdowns with double and triple buffer settings! Sound issue with no buffer vsync and aga demos is not entirely fixed with it though (but seems less pronounced).

I need to check what those values actually mean first

OK

[EDIT: I am adding support for XAudio2. It is MS's "official" replacement for DirectSound but not sure if it is only targed for games (not so low latency).

That's cool, apparently XAudio2 should work better than DSound on Windows Vista / Seven... Somewhere also read that it should provide better quality Audio (I guess the mixing?), but don't know what's the truth behind that..

[Toni Wilen]

Originally Posted by Dr.Venom

EDIT: Before pushing "submit reply", I thought I'd test changing the filter settings from "none" to "null filter" (as it was reported earlier as being a troublemaker) and this completely removes the random slowdowns with double and triple buffer settings! Sound issue with no buffer vsync and aga demos is not entirely fixed with it though (but seems less pronounced).

Do not use "none" filter mode with D3D, it isn't good idea with vsync.
no filter: lock texture, emulate the frame directly to texture, unlock texture.
null or other filter: emulate the frame to internal buffer, lock texture, copy the buffer to texture, unlock texture.

"None" keeps the lock much longer and either page flip stalls while waiting for texture to unlock or texture lock stalls because page flip is still waiting for vsync. (in buffered mode). I am not sure if this can be fixed easily without doing something that isn't allowed (Not sure if you can keep textures locked while doing other D3D calls without causing deadlocks)

That's cool, apparently XAudio2 should work better than DSound on Windows Vista / Seven... Somewhere also read that it should provide better quality Audio (I guess the mixing?), but don't know what's the truth behind that..

Unfortunately it appears to suck for non-games. (Not that surprising, it was orirginally made for XBox after all..) It seems to have "hidden" output buffer that can't be queried for status.

Add few sample buffers to voice buffer, check status of voice buffer in next frame and suddenly all queued buffers are reported as "played". I guess it periodically checks and processes queued buffers to internal output buffer. Very efficient but impossible to get correct buffer status.

btw, WASAPI sound buffer log reported bytes, not samples, so better wait for next version.

[Dr.Venom]

Originally Posted by Toni Wilen

Do not use "none" filter mode with D3D, it isn't good idea with vsync.
no filter: lock texture, emulate the frame directly to texture, unlock texture.
null or other filter: emulate the frame to internal buffer, lock texture, copy the buffer to texture, unlock texture.

"None" keeps the lock much longer and either page flip stalls while waiting for texture to unlock or texture lock stalls because page flip is still waiting for vsync. (in buffered mode). I am not sure if this can be fixed easily without doing something that isn't allowed (Not sure if you can keep textures locked while doing other D3D calls without causing deadlocks

Thanks for the explanation. Would it then also make more sense for the default configuration (starting WinUAE without any config yet selected/created), which starts with direct3d enabled, to also have null filter enabled by default? Or will that cause other problems?

Unfortunately it appears to suck for non-games. (Not that surprising, it was orirginally made for XBox after all..) It seems to have "hidden" output buffer that can't be queried for status.

Add few sample buffers to voice buffer, check status of voice buffer in next frame and suddenly all queued buffers are reported as "played". I guess it periodically checks and processes queued buffers to internal output buffer. Very efficient but impossible to get correct buffer status.

That's too bad :/

btw, WASAPI sound buffer log reported bytes, not samples, so better wait for next version.

OK will do..

Btw, since the A500 cycle exact emulation runs soo well at the lowest sound buffer setting currently, would it be possible to add an even lower buffer setting than the current setting 1 and 2 provide?

On another note. In my experience the RawInput api is working so very well (having noticable lower input latency than DInput) that it might be an idea to promote it to the default input api for WinUAE? Or maybe provide it as a option in the configuration panel?

[Toni Wilen]

Originally Posted by Dr.Venom

Thanks for the explanation. Would it then also make more sense for the default configuration (starting WinUAE without any config yet selected/created), which starts with direct3d enabled, to also have null filter enabled by default? Or will that cause other problems?

Can be done. (It does not really solve anything because rarely anyone starts from scratch)

Btw, since the A500 cycle exact emulation runs soo well at the lowest sound buffer setting currently, would it be possible to add an even lower buffer setting than the current setting 1 and 2 provide?

Adjust config file sound buffer setting manually? (but make sure you do not enter Sound GUI panel because it will check limits)

On another note. In my experience the RawInput api is working so very well (having noticable lower input latency than DInput) that it might be an idea to promote it to the default input api for WinUAE? Or maybe provide it as a option in the configuration panel?

There won't be options because this can't be changed without restart.
But I guess it is time to make it the default, but first I'll add small modification: always enumerate dinput devices and use dinput mode if device type does not have DIDEVTYPE_HID flag.