WASAPI audio on Windows 10

[vagrant]

Originally Posted by Toni Wilen

If only single sample sounds wrong but other samples that play at the same time are not wrong: probably game doing something sound timing sensitive.

Also, buffer size less than 4 or so: you are on your own, don't do it, buy a better pc and so on if you have sound problems

Yeh only single samples. I need to do more testing to confirm whether it only affect new pull mode, it got my attention because I've never heard anything like it before..

I would use my new PC if nvidia had not dropped DVI-I support
But with this hardware & old audio mode, for a long time I've been using sound sound buffer @ 256 samples in low latency/no buffer, without issue.
Btw is it possible to add the option to switch between pull mode & legacy audio mode? (In case new mode is more resource hungry)

[mark_k]

I did some testing with winuae.exe dated 2016-10-12 16:03. Pretty good results: no crackling with sound buffer set to Min in both windowed and non-vsync full-screen modes. My laptop is eight years old so you don't need super-fast hardware to benefit from low sound latency.

Some tips which might help:

• Set power saving mode to high performance
• Open Sound control panel. On the Enhancements tab, check the "Disable all enhancements" box.

Some notes:

• With default format set to 16-bit 44.1kHz in Sound control panel, WinUAE set to WASAPI EX 48kHz, I could use buffer 1 but buffer Min didn't work. Later I changed default format in Sound control panel to 48kHz, after which WASAPI EX buffer Min did work.
• Full-screen, no vsync mode works fine with graphics set to none, double- or triple-buffering. I can set sound buffer to Min and get no crackling. Variable sync seems to work the same as non-vsync mode (no sound crackling).
• With (full-screen) low-latency vsync, or legacy vsync (which forces double-buffered graphics) I need to increase sound buffer to 3 or 4 for crackle-free audio. Could WinUAE sleeping/waiting for the next frame cause that? Would having another thread for servicing audio requests help?
• WinUAE doesn't seem to support/use sample rates higher than 48kHz. If it supported 96kHz could that halve the minimum-possible audio latency?

Windows 10 x86-64 build 10586.589. High Definition Audio Device default format initially 16-bit 44.1kHz (in Sound control panel). WinUAE set to windowed, no vsync, no buffering (though Windows 10 DWM forces vsync?), sound 48kHz.

WASAPI EX buffer 1:
WASAPI: IsOffloadCapable() returned 0 00000000
WASAPI: AUDCLNT_E_BUFFER_SIZE_NOT_ALIGNED: 170 -> 192
WASAPI: IsOffloadCapable() returned 0 00000000
WASAPI: '{0.0.0.00000000}.{b32283a3-ec24-40ed-a52a-7128ab296ef6}'
WASAPI: Exclusive Pull CH=2 FREQ=48000 BUF=192 (192)

Change to buffer 2:
WASAPI: IsOffloadCapable() returned 0 00000000
WASAPI: AUDCLNT_E_BUFFER_SIZE_NOT_ALIGNED: 341 -> 352
WASAPI: IsOffloadCapable() returned 0 00000000
WASAPI: '{0.0.0.00000000}.{b32283a3-ec24-40ed-a52a-7128ab296ef6}'
WASAPI: Exclusive Pull CH=2 FREQ=48000 BUF=352 (352)

Change to buffer 3:
WASAPI: IsOffloadCapable() returned 0 00000000
WASAPI: '{0.0.0.00000000}.{b32283a3-ec24-40ed-a52a-7128ab296ef6}'
WASAPI: Exclusive Pull CH=2 FREQ=48000 BUF=512 (512)

On changing to buffer Min:
WASAPI: IsOffloadCapable() returned 0 00000000
WASAPI: AUDCLNT_E_BUFFER_SIZE_ERROR 0
WASAPI: IsOffloadCapable() returned 0 00000000
Sorry, can't initialize sound.


Change to WASAPI non-exclusive, buffer 1:
WASAPI: IsFormatSupported(2,00000003,48000) (2,44100) 00000001
WASAPI: GetCurrentSharedModeEnginePeriod() CH=2 FREQ=44100 BITS=32 CurrentPeriodInFrames=448
WASAPI: GetSharedModeEnginePeriod() DPIF=448 FPIF=32 MinPIF=128 MaxPIF=448
WASAPI: IsOffloadCapable() returned 0 00000000
WASAPI: InitializeSharedAudioStream() Period=160. HRESULT=00000000
WASAPI: GetCurrentSharedModeEnginePeriod() CH=2 FREQ=44100 BITS=32 CurrentPeriodInFrames=160
WASAPI: '{0.0.0.00000000}.{b32283a3-ec24-40ed-a52a-7128ab296ef6}'
WASAPI: Shared Pull CH=2 FREQ=44100 BUF=176 (352)

With emulation running and sound playing (still WASAPI non-exclusive), I opened Sound control panel and checked "Disable all enhancements". WinUAE locked up, printing this over and over in the log:
WASAPI: GetCurrentPadding() 88890004
WASAPI: GetCurrentPadding() 88890004

I changed default format in Sound control panel to 16-bit 48kHz, killed WinUAE then ran it again. WASAPI non-exclusive, buffer 1:
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=160. HRESULT=00000000
WASAPI: GetCurrentSharedModeEnginePeriod() CH=2 FREQ=48000 BITS=32 CurrentPeriodInFrames=160
WASAPI: '{0.0.0.00000000}.{b32283a3-ec24-40ed-a52a-7128ab296ef6}'
WASAPI: Shared Pull CH=2 FREQ=48000 BUF=176 (352)

Change to buffer Min (still WASAPI non-exclusive):
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)

Change to WASAPI EX (still buffer Min). This time it worked:
WASAPI: IsOffloadCapable() returned 0 00000000
WASAPI: AUDCLNT_E_BUFFER_SIZE_ERROR 0
WASAPI: IsOffloadCapable() returned 0 00000000
WASAPI: '{0.0.0.00000000}.{b32283a3-ec24-40ed-a52a-7128ab296ef6}'
WASAPI: Exclusive Pull CH=2 FREQ=48000 BUF=128 (128)

[Toni Wilen]

Quick hint: try typing something to sound frequency select menu.

EDIT: Ex mode AUDCLNT_E_BUFFER_SIZE_ERROR fixed.

[mark_k]

Aha, thanks! I typed 96000 into the WinUAE Frequency box.

Starting emulation with WASAPI EX buffer Min (Sound control panel default format 16-bit 48kHz):
WASAPI: IsOffloadCapable() returned 0 00000000
WASAPI: AUDCLNT_E_BUFFER_SIZE_ERROR 0
WASAPI: IsOffloadCapable() returned 0 00000000
WASAPI: '{0.0.0.00000000}.{b32283a3-ec24-40ed-a52a-7128ab296ef6}'
WASAPI: Exclusive Pull CH=2 FREQ=96000 BUF=256 (256)

So Windows' minimum seems to be 256 samples at 96kHz (same latency as 128 samples at 48kHz). Sound played OK. Then I changed buffer to 1:
WASAPI: IsOffloadCapable() returned 0 00000000
WASAPI: Initialize() 88890020
Sorry, can't initialize sound.

Change to buffer 2 and sound plays OK again:
WASAPI: IsOffloadCapable() returned 0 00000000
WASAPI: AUDCLNT_E_BUFFER_SIZE_NOT_ALIGNED: 341 -> 352
WASAPI: IsOffloadCapable() returned 0 00000000
WASAPI: '{0.0.0.00000000}.{b32283a3-ec24-40ed-a52a-7128ab296ef6}'
WASAPI: Exclusive Pull CH=2 FREQ=96000 BUF=352 (352)

Any time I set sound buffer to 1, get the same error and no sound. Buffer Min, 2 or higher work fine though???

Edit to add: error 0x88890020 is AUDCLNT_E_INVALID_DEVICE_PERIOD which according to the MSDN IAudioClient::Initialize page means "Indicates that the device period requested by an exclusive-mode client is greater than 500 milliseconds."

That error code can also mean "Indicates that the requested device period specified with the PeriodInFrames is not an integral multiple of the fundamental periodicity of the audio engine, is shorter than the engine's minimum period, or is longer than the engine's maximum period." (MSDN IAudioClient3::InitializeSharedAudioStream page) But that's only for shared mode, which I wasn't using for this test.

[mark_k]

I tested DirectSound mode (winuae.exe 2016-10-12 18:03). Works fine except when buffer is set to Min.

DirectSound, buffer 2:
DS: 00140004 1:00000000 2:00000000 4:00000033 4:00000603 4:00000107 6:0000003F 6:0000060F
DS: 00000000,CH=2,FREQ=48000 'Primary Sound Driver' buffer 2048, dist 512
DS: 1440 = (1920 - 480)
DS: bs=16 w=1280 max=2048 tof=2730 tuf=3640

DirectSound, buffer 1:
DS: DirectSound driver freed
DS: 00140004 1:00000000 2:00000000 4:00000033 4:00000603 4:00000107 6:0000003F 6:0000060F
DS: 00000000,CH=2,FREQ=48000 'Primary Sound Driver' buffer 1024, dist 256
DS: 1024 = (1440 - 416)
DS: bs=8 w=640 max=1024 tof=1365 tuf=1820

DirectSound, buffer Min:
DS: DirectSound driver freed
DS: 00140004 1:00000000 2:00000000 4:00000033 4:00000603 4:00000107 6:0000003F 6:0000060F
DS: 00000000,CH=2,FREQ=48000 'Primary Sound Driver' buffer 0, dist 0
DS: 512 = (960 - 448)
DS: bs=0 w=0 max=0 tof=341 tuf=796
DS: lock failed: 80070057 S=1 F=0007 C=0057 (87) (960 0)
DS: lock failed: 80070057 S=1 F=0007 C=0057 (87) (960 0)
DS: lock failed: 80070057 S=1 F=0007 C=0057 (87) (960 0)
DS: underflow (0 341)

Those last four lines repeat over and over very quickly in the log. (And there's no sound output of course.)

[Toni Wilen]

Originally Posted by ED-209

Btw is it possible to add the option to switch between pull mode & legacy audio mode? (In case new mode is more resource hungry)

Not going to happen and there is is no way it is going to be more resource hungry. Either same or less.

(or use directsound )

[mark_k]

Originally Posted by mark_k

With emulation running and sound playing (still WASAPI non-exclusive), I opened Sound control panel and checked "Disable all enhancements". WinUAE locked up, printing this over and over in the log:
WASAPI: GetCurrentPadding() 88890004
WASAPI: GetCurrentPadding() 88890004

0x8889004 is AUDCLNT_E_DEVICE_INVALIDATED and this page on MSDN could help with handling that condition: Recovering from an Invalid-Device Error.

[mark_k]

I mentioned that the minimum buffer is 256 samples at 96kHz for the Microsoft HD Audio driver, the same latency as 128@48kHz (~2.67ms).

The minimum buffer at 88.2kHz is 224 samples which is ~2.54ms, about 5% lower than 128@48/256@96. So for the absolute lowest latency consider setting WinUAE to 88.2kHz output.

[Toni Wilen]

Originally Posted by mark_k

0x8889004 is AUDCLNT_E_DEVICE_INVALIDATED and this page on MSDN could help with handling that condition: Recovering from an Invalid-Device Error.

I planned to do this someday, also handling situation where device is removed (for example unplugged USB headset etc).

Done now. If AUDCLNT_E_DEVICE_INVALIDATED is returned, first same sound device is opened again, if it fails, default device is selected, if it also fails: sound is switched off.

[mark_k]

Testing now with winuae.exe dated 2016-10-13 18:25.

With the Windows sound default set to 48kHz, starting WinUAE with WASAPI EX 88.2kHz Min buffer resulted in:
WASAPI: IsOffloadCapable() returned 0 00000000
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)

However after setting the Windows default to 88.2kHz, running WinUAE again (still WASAPI EX 88.2kHz), the log reported 224 not 256:
WASAPI: IsOffloadCapable() returned 0 00000000
WASAPI: '{0.0.0.00000000}.{b32283a3-ec24-40ed-a52a-7128ab296ef6}'
WASAPI: Exclusive Pull CH=2 FREQ=88200 BUF=224 (224)

Maybe a Windows/driver bug? The default for shared audio shouldn't affect exclusive mode surely.


I had WinUAE playing WASAPI EX 88.2kHz audio. While audio played I changed default sound format in Sound control panel from 48kHz to 88.2kHz. WinUAE output this to the log then hung:
WASAPI: GetBuffer() 88890026

0x88890026 is AUDCLNT_E_RESOURCES_INVALIDATED (no mention of that on MSDN... ).


WASAPI non-exclusive audio 88.2kHz (with Sound control panel default set to 88kHz). Buffer Min results in this:
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)

So Windows reported minimum period 224, but you use 492 (the same used when buffer size is set to 1).

[Toni Wilen]

Originally Posted by mark_k

0x88890026 is AUDCLNT_E_RESOURCES_INVALIDATED (no mention of that on MSDN... ).

Seems to be Windows 10 v1607 only error code.

EDIT: AUDCLNT_E_RESOURCES_INVALIDATED now does same as AUDCLNT_E_DEVICE_INVALIDATED = re-open the device.

So Windows reported minimum period 224, but you use 492 (the same used when buffer size is set to 1).

Final buffer size needs to be queried (AudioClient->GetBufferSize), you can't force it.

[Dr.Venom]

Now that the Wasapi modes are working so great, I wondered whether it would be useful to take account of the "calibrated" soundcard frequency.

Just as that " 60Hz" screenmodes are almost never exactly 60.0000hz, it appears a soundcard output is also not exactly the advertised rate. I.e. 48Khz may actually be someting like 48000.27Hz.

Attached is a little tool which I hope the author doesn't mind me including it here. It's from the ASIO implementation/patch of GroovyMAME.

You can run the "batool64.exe" and it will supply some information on the enabled sounddevices. For this test to work you need an ASIO enabled driver. In case your default doesn't have that, you could use/install ASIO4ALL.


Running batool64 for my setup gives for example:

dev 0: ASIO 2.0 - ESI Juli@
driver: C:\WINDOWS\system32\JulaASIO.dll
dev 1: ASIO4ALL v2
driver: C:\Program Files (x86)\ASIO4ALL v2\asio4all64.dll
    out 0: HD Audio-luidspreker 1 (group 0, format 18)
    out 1: HD Audio-luidspreker 2 (group 0, format 18)
    out 2: HD Audio-luidspreker 3 (group 0, format 18)
    out 3: HD Audio-luidspreker 4 (group 0, format 18)
    out 4: HD Audio-luidspreker 5 (group 0, format 18)
    out 5: HD Audio-luidspreker 6 (group 0, format 18)
    out 6: HD Audio-luidspreker 7 (group 0, format 18)
    out 7: HD Audio-luidspreker 8 (group 0, format 18)

usage: batool64 [device] [sample rate] [# decimals] | [--cp]

So if I run "batool64 1" it will run a calibration test via asio4all on my realtek chip. The output will be the "real" rate of the card.

Mostly the onboard audio chips (realtek) are quite accurate and close to 48000Hz. But for pci cards this may differ a bit more.

The rate for my realtek is 48000.02Hz, and for my PCI-E Juli@XTe 48000.70Hz.

Now these seem only small deviations, but somewhere along the line they will eat the audio buffer more quickly (or more slowly for <48.000 values) then the emulator assumes.

Could it as such possibly be useful to create a calibration test/tool for WinUAE's Wasapi mode, and take the result into account for the sound resampling rate (which currently is based of " VSync calibrated" only)?

I know the impact will be minor, but with the wasapi mode now being so low latency, it could be a " dotting the i" in terms of accuracy?

[Dr.Venom]

Originally Posted by Toni Wilen

352 = Paula buffer size which is half the size of wasapi buffer (perhaps it should be even smaller), shared mode does not require that complete buffer is filled. There is also hidden "reservour" buffer that keeps the overflow if Paula buffer didn't fit 100%. It is normally mostly empty. (This can't happen in exclusive mode, it always uses wasapi buffer sized requests).

Value in parenthesis is wasapi buffer size.

I am not sure if I want to mess with this too much, can't really improve it much more.

Done some more testing with wasapi-ex mode and low latency vsync. In this case I need to change the buffer setting (while using HD audio driver onboard realtek) to 3 or even 4, otherwise there will be slight crackles / pull overflows very occasionally. For wasapi shared I currently have it at setting 2 (whichs runs wunderful).

With regards to timing I had another thought. Are you in low latency vsync mode still burst emulating chuncks of 2ms (every time waiting for real-time to match emulate machine time)?

What if, only when buffer size setting is really small, you would instead align them with the wasapi buffer size "time" and synchronize with the pull events?

So for example wasapi size is 352:

- Wait for pull event
- Burst emulate time equivalent of 352 samples, fill buffer
- wait for pull event
- burst emulate, etc..

Possibly this would allow for even tighter synchronization when buffer setting is ultra small?

(Even though I can imagine this may not be easy when combining it with final wait for vsync..)

[mark_k]

Originally Posted by Dr.Venom

Mostly the onboard audio chips (realtek) are quite accurate and close to 48000Hz. But for pci cards this may differ a bit more.

The rate for my realtek is 48000.02Hz, and for my PCI-E Juli@XTe 48000.70Hz.

Now these seem only small deviations, but somewhere along the line they will eat the audio buffer more quickly (or more slowly for <48.000 values) then the emulator assumes.

I wonder how useful those figures are. Which clock source in your PC are they calculated with reference to? Unless you have some kind of atomic clock and batool64 uses that, surely the tolerance/error in the PC clock reference would be higher than the tiny difference between 48000.00 and 48000.02 (say).

That's a difference of less than 0.000042%; to put that in perspective, if the timing reference is a 2GHz CPU clock, that would be a difference of 833Hz.

While (I think) figures of 48000.02 & 48000.70 might not exactly match the real-world actual sample rates as you could measure with some calibrated instrument, the relative difference between them probably is accurate. And (if tiny deviations in the sample rate matter at all) the figures probably are relevant, in that WinUAE's timing will be based off the same source. In other words, WinUAE "sees" 48000.70Hz, even if the real-world actual rate is 48000.01Hz or whatever.

[mark_k]

Testing winuae.exe 2016-10-13 19:37.

Default format set to 16-bit 176.4kHz in Sound control panel.

I ran WinUAE, loaded a config (WASAPI EX) and and manually entered 176400 in the Frequency box in sound settings. On starting emulation:
WASAPI: IsOffloadCapable() returned 0 00000000
WASAPI: Initialize() 88890020
Sorry, can't initialize sound.

On pressing F12 I noticed that the Frequency box now says 96000. Similarly, if I enter 176400 then save the config, loading it again has 96000 in the Frequency box.

After changing to WASAPI non-exclusive and entering 176400 in the box, continuing emulation there is sound:
WASAPI: IsFormatSupported(2,00000003,96000) (2,176400) 00000001
WASAPI: GetCurrentSharedModeEnginePeriod() CH=2 FREQ=176400 BITS=32 CurrentPeriodInFrames=1792
WASAPI: GetSharedModeEnginePeriod() DPIF=1792 FPIF=32 MinPIF=448 MaxPIF=1792
WASAPI: IsOffloadCapable() returned 0 00000000
WASAPI: InitializeSharedAudioStream() Period=448. HRESULT=00000000
WASAPI: GetCurrentSharedModeEnginePeriod() CH=2 FREQ=176400 BITS=32 CurrentPeriodInFrames=448
WASAPI: '{0.0.0.00000000}.{b32283a3-ec24-40ed-a52a-7128ab296ef6}'
WASAPI: Shared Pull CH=2 FREQ=176400 BUF=492 (984)

Pressing F12 again, 176400 is in the Frequency box as it should be. But if I save and load the config, it gets reset to 96000.

Edit to add: the problem is probably this check in values_from_sounddlg():

if (workprefs.sound_freq > 96000)
	workprefs.sound_freq = 96000;

[Dr.Venom]

Originally Posted by mark_k

I wonder how useful those figures are. Which clock source in your PC are they calculated with reference to? Unless you have some kind of atomic clock and batool64 uses that, surely the tolerance/error in the PC clock reference would be higher than the tiny difference between 48000.00 and 48000.02 (say).

That's a difference of less than 0.000042%; to put that in perspective, if the timing reference is a 2GHz CPU clock, that would be a difference of 833Hz.

Ofcourse.

While (I think) figures of 48000.02 & 48000.70 might not exactly match the real-world actual sample rates as you could measure with some calibrated instrument, the relative difference between them probably is accurate. And (if tiny deviations in the sample rate matter at all) the figures probably are relevant, in that WinUAE's timing will be based off the same source. In other words, WinUAE "sees" 48000.70Hz, even if the real-world actual rate is 48000.01Hz or whatever.

What would that mean to WinUAE, could we possibly benefit from some calibration adjustment?

Your point is well taken on the accuracy of the clock timer measuring these differences though, it could well just be smoke and mirrors.

On the other hand, the research from the GroovyMAME forums showed larger deviations even than the 0.7Hz for some users. The sound stability with GroovyMAME ASIO also got more stable after correcting for these "measured" differences for various users (we're talking very low latencies for GMASIO). So I guess there may be some truth to it.

Did you have a chance to do a check with the batool for your systems?

Possibly a "quick and dirty" inbetween road could be for Toni to allow for a temporary commandline manual "adjustment factor" that gets applied to the internal resampling frequency calculation. Purely for testing purposes to see whether + or - "0.XHz/48000Hz" adjustments have any noticable effect on the sound stability.

[mark_k]

Extracts from the MSDN IAudioClient::Initialize page, with emphasis added:

To achieve the minimum stream latency between the client application and audio endpoint device, the client thread should run at the same period as the audio engine thread. The period of the engine thread is fixed and cannot be controlled by the client. Making the client's period smaller than the engine's period unnecessarily increases the client thread's load on the processor without improving latency or decreasing the buffer size. To determine the period of the engine thread, the client can call the IAudioClient::GetDevicePeriod method. [...]

A client has the option of requesting a buffer size that is larger than what is strictly necessary to make timing glitches rare or nonexistent. Increasing the buffer size does not necessarily increase the stream latency. For a rendering stream, the latency through the buffer is determined solely by the separation between the client's write pointer and the engine's read pointer.
...
For an exclusive-mode stream that uses event-driven buffering, the caller must specify nonzero values for hnsPeriodicity and hnsBufferDuration, and the values of these two parameters must be equal. The Initialize method allocates two buffers for the stream. Each buffer is equal in duration to the value of the hnsBufferDuration parameter. Following the Initialize call for a rendering stream, the caller should fill the first of the two buffers before starting the stream. [...] While the stream is running, the system alternately sends one buffer or the other to the client—this form of double buffering is referred to as "ping-ponging". Each time the client receives a buffer from the system (which the system indicates by signaling the event), the client must process the entire buffer. For example, if the client requests a packet size from the IAudioRenderClient::GetBuffer method that does not match the buffer size, the method fails. Calls to the IAudioClient::GetCurrentPadding method are unnecessary because the packet size must always equal the buffer size. In contrast to the buffering modes discussed previously, the latency for an event-driven, exclusive-mode stream depends directly on the buffer size.

Does the first emphasised sentence above mean that for WASAPI shared audio, the sound buffer size setting in WinUAE doesn't necessarily affect latency?

[Toni Wilen]

I don't think I want to optimize this any more. I don't want to make directsound sound requirements totally different in core emulation, it is already getting a bit too messy (and unfortunately directsound has to stay for XP compatibility reasons)

Does the first emphasised sentence above mean that for WASAPI shared audio, the sound buffer size setting in WinUAE doesn't necessarily affect latency?

I must be missing something because it makes no sense. Why would you want to allocate larger buffer if you don't fill it completely? And if you don't fill it completely, result is same as smaller buffer (less latency, higher change of glitches). It does not compute.

And why would then Windows 10 support even smaller buffers if above is true?

Or "rendering stream" means something different..

[Dr.Venom]

Originally Posted by Toni Wilen

I don't think I want to optimize this any more. I don't want to make directsound sound requirements totally different in core emulation, it is already getting a bit too messy (and unfortunately directsound has to stay for XP compatibility reasons)

While reading this some questions came up...
Note that these questions may come across as somewhat opiniated, but for the better part they are more an open interest on the future development path.

If you would do further optimizations on Wasapi, for a moment separating this from your other comment about maintaining XP compatibility, would that potentially make significant steps ahead in stability and or latency?

And a second more philosophical question: would your enjoyment of developing WinUAE not increase when you would not be held back anymore by maintaining this legacy XP compatibility?

The main reason for asking this, is that I have a feeling it would be a missed opportunity for the larger part of the userbase (including myself) if you're potentially withholding future improvements, because of this "legacy" compatibility with XP. Which (again IMO) is an "outdated, unsecure OS, buried officially in 2014, with a small userbase, which will get smaller by the month".

If in any way your heart would rather develop unrestrained for WinUAE (no, i'm not trying to influence you ), maybe it could be considered, just like with driver support for old graphics cards, to make a certain version (3.4.0?) the last version that has XP support.

Or, an inbetween road could be keeping XP compatibility, but losing the DSOUND stuff from a certain version onwards, and directing these XP users to that last version. Or if they are inclined to still use a newer version, direct them to ASIO4ALL (which supports Win 98SE/ME/2k/XP and up), and using WinUAE's Portaudio:ASIO mode with ASIO4ALL.

For me these options sound like they could offer an acceptable gradual path to letting go of the legacy XP compatibility, such that future improvements for the larger part of the userbase may be developed unrestrained.

[Toni Wilen]

XP compatibility has to stay (but it goes away when MSVC drops XP support. So far it hasn't happened), even if I don't want it. There is not really nothing to discuss.

No extra drivers must be required. XP does have WDM-KS but it is like WASAPI-EX.