wasapi cpu usage

[meynaf]

Hi,

Normally i use DSound. Wanted to see if Wasapi would help with occasionnal buffer misses i get.
But then it starts using *heaps* of cpu power !

Win10, Winuae 4.9.1.

Normal cpu use : around 18% with no sound (relative high for a Ryzen5 due to filter settings).
With DSound : 22%. Seems "normal" (for a windows box).
With Wasapi (regardless shared or ex), it gets around 80-90% !

So ok, it otherwises works fine, but nevertheless...
CPU idle is set to 100% but lowering it of course doesn't help.

Raising buffer size can bring cpu use back to normal but only at 9-10. With 8 i'm already at 75%. Oddly enough, lower settings don't make the things worse : it still works with "min" setting (though probably not reliable in the long run).
DSound can get down to 2 ; i normally use 4.

Using cpu cycle exact rather than fastest possible brings cpu usage to... 0% but it misses notes (i.e. some channel isn't played). Fastest possible raises cpu use, JIT or not, but without JIT it misses notes too.

This looks completely crazy. If Wasapi is low level, DSound should be using it and have same issues, shouldn't it ?

What is happening ?
Is it known issue, has anyone else had this ?
Is it inherent to the method ?
Some driver issue ?
Windows being stupid OS ?

[rutra80]

Are you refering to CPU use shown by WinUAE or Task manager?
Fastest possible will always show 100 in WinUAE but Task manager will show a fraction dependent on number of cores (WinUAE uses 1 core).

Tested in menu of Upfront - Cool Fridge demo, A500 CE config on my i7-4790K with min buffer, I get in WinUAE:

• ~2% no sound emulation
• ~25% WASAPI
• ~90% DSound

Task manager always shows ~17%

My money is on the driver. If you're refering to Task manager then maybe your WASAPI uses additional cores for some sound enhancements?
Make sure that in Windows sound properties you're not using anything higher than 16bit 48000Hz (no point) and that you have all unnecessary enhancements disabled.

[meynaf]

Originally Posted by rutra80

Are you refering to CPU use shown by WinUAE or Task manager?

The one shown by Winuae. Task manager says 11%.

Originally Posted by rutra80

Fastest possible will always show 100 in WinUAE but Task manager will show a fraction dependent on number of cores (WinUAE uses 1 core).

Not when emulated cpu does nothing and IDLE slider has been pushed to max.

Originally Posted by rutra80

Tested in menu of Upfront - Cool Fridge demo, A500 CE config on my i7-4790K with min buffer, I get in WinUAE:

• ~2% no sound emulation
• ~25% WASAPI
• ~90% DSound

Task manager always shows ~17%

For testing I use Delitracker2 playing some mod under WB.

Originally Posted by rutra80

My money is on the driver. If you're refering to Task manager then maybe your WASAPI uses additional cores for some sound enhancements?
Make sure that in Windows sound properties you're not using anything higher than 16bit 48000Hz (no point) and that you have all unnecessary enhancements disabled.

It's set to 48000, nothing special in any setting that i could find (there aren't many).
Other cores are not used much, it's really single core issue.

I disabled, even tried to completely uninstall damned ASUS AI noise-cancelling output that was pre-installed (which ate the music rather than enhancing it when i tried it so it wasn't used/useful anyways). No change ; seems this has nothing to do with the issue.

If it is the driver, how would DSound work fine ? Everything should be affected...

[Toni Wilen]

CPU% can't be always trusted because it counts anything that takes time from UAE main process as using CPU, even if it is only waiting.

Check using normal A500 quickstart mode first. Does it also show higher CPU% than directsound?

[meynaf]

Quickstart A500 works fine for both. It says 0% cpu use.
Quickstart A1200 also works.
Things get crazy as soon as cpu is set to fastest possible (of course with IDLE slider at max, otherwise it's 100%).

[rutra80]

Must be something funky how idle cycles are inserted and how and what is counted as WinUAE and non-WinUAE cycles.
Anyway, why are you using IDLE slider at all? It was meant for single core CPUs to not grind PC to a halt. Your Ryzen has plenty of cores and good power management - WinUAE utilizing whole 1 core won't significantly affect neither system performance, battery life nor temperatures...

[meynaf]

Task manager says 5% cpu use for DSound and 12-13% for Wasapi (11% if using default buffer size of 8).
So the winuae counter is correct.

IDLE slider works fine and is nice indicator on emulated cpu use too.
Using 100% cpu even single core wouldn't only be wasteful and not a great idea in summer, it also only "hides" the problem. Breaking the thermometer isn't the right way to fix the temperature.

About good power management, well, it's not - at least on win10 side. Sometimes cpu% in winuae lowers under normal use for no apparent reason, leading to fps decrease and sound massively missing buffers (regardless of what is used). But that's another problem for later (if not linked to that one).

[rutra80]

Toni can you confirm that IDLE slider gives any indication of emulated CPU use?

As far as I'm aware 68k nor Amiga haven't had any power management, there was no background task executing HALT command nor any kind of use measurement - even "nothing" was done at full power, full voltages, full clock.

By moving IDLE slider too far right you may be starving the emulation. It is known that at full right issues happen.

[meynaf]

Originally Posted by rutra80

Toni can you confirm that IDLE slider gives any indication of emulated CPU use?

You don't need Toni to see that cpu use indicated is total use for emulated chipset and emulated cpu. So, while not very precise, you can easily see if emulated cpu is idle or working at full power. You do, however, need to check "fastest" to see this.

Originally Posted by rutra80

As far as I'm aware 68k nor Amiga haven't had any power management, there was no background task executing HALT command nor any kind of use measurement - even "nothing" was done at full power, full voltages, full clock.

Wrong. Exec uses STOP instruction in its idle loop. This gives the emulator an opportunity to free cpu, this is what IDLE slider is for.
Using this wait time at 100% host cpu usage, even single core, is for me unacceptable waste.

Originally Posted by rutra80

By moving IDLE slider too far right you may be starving the emulation. It is known that at full right issues happen.

But this shouldn't in any manner depend on what kind of sound output is chosen.
In addition, if emulated cpu works 100%, it gives 100% too even with IDLE slider at max. It will not aggressively free cpu.
Only issue is that it may add some latencies, depending on system activity. This ends up in more frequent audio buffer misses.

[Toni Wilen]

CPU Idle is very basic, it only switches to approximate CPU speed when emulated CPU has been idle long enough (delay depends on CPU Idle slider).

It is very difficult to do this well because emulator still needs to emulate everything else normally.

It could "predict" when next interrupt(s) are about come when CPU is STOPped and prepare for it but it can get introduce other side-effects and would be more complex.

[meynaf]

But where's the link with what happens here ?

DSound is ok, not Wasapi unless buffer size is set to very high.
In addition - linked to this or not i do not know - as i mentioned above, cpu sometimes starts to throttle and frame rate is lowered, even with idle slider at 20%.

What's the basic emulation algorithm anyway ? I thought it was just computing a frame, registering events and then emulating things, then waiting for the next one...
How is the cpu taken back after having been idle ?
What is the time base on the host side ?

[Toni Wilen]

I don't know and I can't duplicate it here. But WASAPI and DS are quite different, WinUAE WASAPI mode use "pull mode" where driver requests new data when it needs more, DS uses "push" mode where UAE sends new data when it has new data ready. "Pull mode" means reduced latency and less glitches.

Minimum "sleep time" WinUAE uses is 2ms (due to Windows restrictions, it can't wait less than 1ms and even 1ms is not guaranteed = 2ms is mostly guaranteed minimum).

In fastest possible CPU mode CPU emulation is run few milliseconds of real time, then matching "frame time" is emulated (chipset), alternating CPU and chipset until complete frame (20ms if PAL) has been finished. JIT can introduce more "jitter" because whole compile JIT block is executed (including possible loops) before execution returns back to main emulator. Getting all emulation modes work without too much timing issues is not trivial.

I am not interested in improving this at the moment and this is not trivial "fix".

[meynaf]

Seems DS is in some way better than Wasapi, as at least it allows knowing if we're good or not - Wasapi does not update "snd" display.

As you can't reproduce, i can do tests if you can find any.

I guess i could just use DS but i have other problems and they might be linked.

[rutra80]

I suggest measuring with Task Manager if WASAPI indeed uses more host CPU, and benchmarking emulated Amiga to see if WASAPI indeed slows it down.
Also refer to below image to check whether you have optimal Windows audio settings:

[meynaf]

Originally Posted by rutra80

I suggest measuring with Task Manager if WASAPI indeed uses more host CPU,

See post #7. It does.

Originally Posted by rutra80

and benchmarking emulated Amiga to see if WASAPI indeed slows it down.

Appears to be the right track : benchmark does not see much of a difference, indicating it spends most of that time waiting.

Originally Posted by rutra80

Also refer to below image to check whether you have optimal Windows audio settings:

I don't have this enhancements tab.