WASAPI audio on Windows 10

[mark_k]

I'm guessing you're not desperately keen to add WDM-KS support to WinUAE?

At least in a VirtualBox XP VM DirectSound gives about 1 second latency. Presumably latency on real hardware wouldn't be as bad, but more than WDM-KS would allow.

[Toni Wilen]

Originally Posted by mark_k

I'm guessing you're not desperately keen to add WDM-KS support to WinUAE?

No because it is exclusive. Everyone would hate it. It is worse than DirectSound from user point of view.

[mark_k]

The use case would be the same as WASAPI exclusive on Vista+: lower latency.

[mark_k]

I tested WinUAE 3.4.0b14. Some notes (see extracts from log output below)...

WASAPI EX: At high sample rates (88.2kHz+) setting sound buffer size to 1 or 2 results in no sound playing. I assume that's because the buffer that WinUAE requests is smaller than the hardware/driver minimum. Setting buffer size to Min does work. For high sample rates, perhaps you could scale all buffer size settings >= 1 so they are larger than the driver minimum?

WASAPI EX and shared: While WinUAE is playing sound, opening Sound control panel and changing the sound format (e.g. from 48kHz to 88.2kHz) causes WinUAE to stop playing sound. That's not really a problem, but if you press F12, change sound emulation back to Enabled and click OK, sound plays again even though no other audio settings were changed. Perhaps WinUAE could restart sound playing automatically then?

Repeat the above, but press F12 to open settings window (which pauses emulation) before changing default format in Sound control panel. When you click OK to continue emulation WinUAE hangs (stops responding).


At 176.4kHz, Min buffer sound works:
WASAPI: AUDCLNT_E_BUFFER_SIZE_NOT_ALIGNED: 0 -> 480
WASAPI: '{0.0.0.00000000}.{b32283a3-ec24-40ed-a52a-7128ab296ef6}'
WASAPI: Exclusive Pull CH=2 FREQ=176400 BUF=480 (480)

On changing buffer setting to 1 or 2 there is no sound and this output:
WASAPI: Initialize() 88890020
Sorry, can't initialize sound.

Sound works with buffer 3 (and higher). The same applies for 192kHz.

At 88.2kHz, Min buffer works:
WASAPI: AUDCLNT_E_BUFFER_SIZE_NOT_ALIGNED: 0 -> 256
WASAPI: '{0.0.0.00000000}.{b32283a3-ec24-40ed-a52a-7128ab296ef6}'
WASAPI: Exclusive Pull CH=2 FREQ=88200 BUF=256 (256)

No sound with Buffer = 1. Buffer = 2 and higher work.


Shared WASAPI. Sound control panel format set to 48kHz 16-bit. WinUAE set to 88.2kHz, buffer Min:
WASAPI: IsFormatSupported(2,00000003,88200) (2,48000) 00000001
WASAPI: GetCurrentSharedModeEnginePeriod() CH=2 FREQ=48000 BITS=32 CurrentPeriodInFrames=480
WASAPI: GetSharedModeEnginePeriod() DPIF=480 FPIF=32 MinPIF=128 MaxPIF=480
WASAPI: IsOffloadCapable() returned 0 00000000
WASAPI: InitializeSharedAudioStream() Period=128. HRESULT=00000000
WASAPI: GetCurrentSharedModeEnginePeriod() CH=2 FREQ=48000 BITS=32 CurrentPeriodInFrames=128
WASAPI: '{0.0.0.00000000}.{b32283a3-ec24-40ed-a52a-7128ab296ef6}'
WASAPI: Shared Pull CH=2 FREQ=48000 BUF=140 (280)

Sound plays, but at the shared rate of 48kHz (which is correct). With sound playing, I opened Sound control panel and changed the default format to 88.2kHz. Control panel showed a dialog box saying:
"The device is being used by another application. If you continue, that
application may stop working.
Do you want to continue?"

Clicking Yes resulted in this log output:
WASAPI: GetCurrentPadding() 88890004
WASAPI: IsFormatSupported(2,00000003,48000) (2,88200) 00000001
WASAPI: GetCurrentSharedModeEnginePeriod() CH=2 FREQ=88200 BITS=32 CurrentPeriodInFrames=896
WASAPI: GetSharedModeEnginePeriod() DPIF=896 FPIF=32 MinPIF=224 MaxPIF=896
WASAPI: IsOffloadCapable() returned 0 00000000
WASAPI: InitializeSharedAudioStream() Period=224. HRESULT=00000000
WASAPI: GetCurrentSharedModeEnginePeriod() CH=2 FREQ=88200 BITS=32 CurrentPeriodInFrames=224
WASAPI: '{0.0.0.00000000}.{b32283a3-ec24-40ed-a52a-7128ab296ef6}'
WASAPI: Shared Pull CH=2 FREQ=88200 BUF=246 (492)

And sound stopped playing. (On pressing F12, sound is set to disabled but emulated). Enable it and sound plays again:
WASAPI: GetCurrentSharedModeEnginePeriod() CH=2 FREQ=88200 BITS=32 CurrentPeriodInFrames=896
WASAPI: GetSharedModeEnginePeriod() DPIF=896 FPIF=32 MinPIF=224 MaxPIF=896
WASAPI: IsOffloadCapable() returned 0 00000000
WASAPI: InitializeSharedAudioStream() Period=224. HRESULT=00000000
WASAPI: GetCurrentSharedModeEnginePeriod() CH=2 FREQ=88200 BITS=32 CurrentPeriodInFrames=224
WASAPI: '{0.0.0.00000000}.{b32283a3-ec24-40ed-a52a-7128ab296ef6}'
WASAPI: Shared Pull CH=2 FREQ=88200 BUF=246 (492)

While sound playing, change format in Sound control panel back to 48kHz. WinUAE sound stops with this log output:
WASAPI: GetCurrentPadding() 88890004
WASAPI: IsFormatSupported(2,00000003,88200) (2,48000) 00000001
WASAPI: GetCurrentSharedModeEnginePeriod() CH=2 FREQ=48000 BITS=32 CurrentPeriodInFrames=480
WASAPI: GetSharedModeEnginePeriod() DPIF=480 FPIF=32 MinPIF=128 MaxPIF=480
WASAPI: IsOffloadCapable() returned 0 00000000
WASAPI: InitializeSharedAudioStream() Period=128. HRESULT=00000000
WASAPI: GetCurrentSharedModeEnginePeriod() CH=2 FREQ=48000 BITS=32 CurrentPeriodInFrames=128
WASAPI: '{0.0.0.00000000}.{b32283a3-ec24-40ed-a52a-7128ab296ef6}'
WASAPI: Shared Pull CH=2 FREQ=48000 BUF=140 (280)


Now try something different... Sound cpl 48kHz, run WinUAE, start emulation with WASAPI shared sound, it plays at 48kHz as above. Press F12 to open settings window. Using Sound cpl change default format (e.g. to 88.2kHz). Continue emulation. WinUAE hangs (stops responding) with this log output:
WASAPI: Resume GetBuffer() 88890004

[Toni Wilen]

Originally Posted by mark_k

The use case would be the same as WASAPI exclusive on Vista+: lower latency.

XP-only improvement: not really.

Originally Posted by mark_k

WASAPI EX and shared: While WinUAE is playing sound, opening Sound control panel and changing the sound format (e.g. from 48kHz to 88.2kHz) causes WinUAE to stop playing sound. That's not really a problem, but if you press F12, change sound emulation back to Enabled and click OK, sound plays again even though no other audio settings were changed. Perhaps WinUAE could restart sound playing automatically then?

There is no guarantee mode change is instant. I'll need to check WASAPI event notifications, they apparently are meant to detect on the fly sound mode changes.

WASAPI: Initialize() 88890020

This is now handled. (Find lowest supported period and use it)

Now try something different... Sound cpl 48kHz, run WinUAE, start emulation with WASAPI shared sound, it plays at 48kHz as above. Press F12 to open settings window. Using Sound cpl change default format (e.g. to 88.2kHz). Continue emulation. WinUAE hangs (stops responding) with this log output:
WASAPI: Resume GetBuffer() 88890004

Fixed.

[mark_k]

Testing with winuae.exe 2016-10-30 17:54, this time in a Windows Server 2008 VirtualBox VM.

With the audio service not running (the default behaviour), on starting emulation with WASAPI EX selected, the log line should print the error code in hex, not decimal:
WASAPI: Activate() -2004287472

After starting the audio service...

Start emulation with WASAPI shared audio. While sound plays press F12. Wait a while then click Cancel. WinUAE hangs (using ~100% CPU). That doesn't happen every time. It seems pressing F12 then immediately clicking Cancel doesn't cause the hang, but waiting at least several seconds before clicking Cancel does.

I didn't see the hang with WASAPI EX or DirectSound.

Edit to add: same issue with beta 14.

[mark_k]

Still testing 2016-10-30 17:54 winuae.exe.

Windows 10: While sound is playing, open Sound control panel and un-check "Allow applications to take exclusive control of this device". Emulation continues with no sound and this in the log:
WASAPI: GetBuffer() 88890026
WASAPI: IsFormatSupported(2,00000003,48000) (-1,-1) 8889000E
Reopen sound failed. Retrying with default device.
WASAPI: IsFormatSupported(2,00000003,48000) (-1,-1) 8889000E

0x8889000E is AUDCLNT_E_EXCLUSIVE_MODE_NOT_ALLOWED. Maybe fall back to shared mode in that case?

Windows 7: Instead of emulation continuing with no sound, WinUAE hangs with no log output.

[Toni Wilen]

Originally Posted by mark_k

Start emulation with WASAPI shared audio. While sound plays press F12. Wait a while then click Cancel. WinUAE hangs (using ~100% CPU). That doesn't happen every time. It seems pressing F12 then immediately clicking Cancel doesn't cause the hang, but waiting at least several seconds before clicking Cancel does.

Can't duplicate. Manually forced crash dump file (from official beta, task manager -> create dump file) may help to debug this.

Sound not retrying properly after Windows control panel parameter change was a bug (re-open succeeded but sound was left in paused mode).

[mark_k]

I neglected to mention that the problem happens with a Windows Server 2008 VM. I have uploaded a dump file (~18.55MB, created with 3.4.0b14) to

https://www.media!fire.com/?04zcoiaat7une5r

Remove ! after pasting URL into your web browser.

[Toni Wilen]

Argh. I forgot to change symbol file path when compiler was changed. Wait for next beta and create new dump if it still crashes.

EDIT: winuae.7z updated, one possible infinite loop found if sound mode changes in wrong place and time.

[mark_k]

Latest winuae.exe still has the problem.

[mark_k]

Dump file created with 3.4.0b15 (~27MB compressed):

https://www.media!fire.com/?q9ic94kc4m49pcm

[Toni Wilen]

Unfortunately dump won't help, it is waiting for buffer to empty but buffer isn't emptying, like wasapi isn't playing anything. It also should wait 1ms between each polls to prevent 100% CPU usage.

It really is Server 2008? Not 2008R2? Which VM? (=which emulated sound card?)

[mark_k]

Yes, Server 2008 not R2. So the problem could show up with Windows Vista too, but I no longer have Vista installed on native hardware to check.

I'm using VirtualBox with emulated HD Audio controller. In Device Manager it says the Microsoft HD Audio driver is used:
Driver Provider: Microsoft
Driver Date: 21/06/2006
Driver Version: 6.0.6002.18005

Worth noting, there is very high audio latency which is probably due to VirtualBox's emulation of the hardware. E.g. with sound playing, after pressing F12 it takes about a second for the sound to stop playing. But that may not be relevant to this problem.

I also tried with the VM configured for emulated AC97 sound hardware. That shows up as "Intel(r) 82801AA AC'97 Audio Controller" in device manager, uses a Microsoft driver too. With that starting emulation with WASAPI shared audio causes WinUAE to hang immediately. Exclusive does work OK.

If you feel like testing this yourself in a Vista VM (and don't have one already) I could upload the Vista VM which was formerly available from http://modern.ie/.

[Toni Wilen]

I have old x64 Vista VM (VMWare Player), can't duplicate any hangs. Same High Definition Audio Device driver, same version numbers. Same about 1s latency too..

[mark_k]

I installed VMWare player and created a new Windows Server 2008 (x86) VM.

[Aside: Performance of WinUAE in the VMWare VM sucks quite a bit compared to VirtualBox. With VirtualBox I could at least get smooth 50Hz scrolling. The VMWare display is very juddery and sound crackles seemingly regardless of the sound buffer setting. Maybe the difference is due to the VirtualBox VM set to not emulate I/O APIC, but that setting not being changeable in VMWare Player? On the other hand sound latency didn't seem huge; sound stops very quickly after pressing F12.]

I couldn't reproduce the hang problem, however I did get WinUAE to hang once. Dump file for that (< 18MB):

https://www.media!fire.com/?9ff1adjbvsratdt

[Toni Wilen]

I don't have any winuae performance or sound problems in vmware. (I originally used vmware because it was first vm that introduced d3d support that didn't suck 100%)

[mark_k]

With VirtualBox emulating I/O APIC (required for multi-core guests) performance tanks. I think VMWare always emulates I/O APIC with no ability to disable that (at least, not in VMWare Player). Hence the poor VMWare VM performance for me. The performance difference could be smaller on more modern CPUs.

[Dr.Venom]

What is currently the best / most preferred method to determine whether a certain WinUAE soundbuffer setting is 100% glitch free?

For example in Wasapi-EX mode and low latency vsync, the lowest buffer settings for my setup produce some glitches (i.e. for setting Min, 1 and 2), but now I want to know whether buffer setting 3 is really 100% glitch free when run for a longer time.

Since this is sometimes hard to judge during game and demo music, I'm looking for the best way to go about it.

Should I look for zero "pull overflow" messages in the log to ascertain that the audio is 100% glitch free, or could that still mean there might be some (unnoticable?) glitches in the stream?

Or would running Protracker in the emulated environment using the "tunetone" function to produce a constant sound and listening to that for any glitches be the best way? Any advice on how to best determine whether an audio setting is 100% glitchfree would be welcome.

[Toni Wilen]

100% glitch free is impossible to guarantee. Outside world can steal CPU time to cause glitches or some very specific emulation situation may need 10x more CPU time than the average.