WASAPI audio on Windows 10

[mark_k]

I was reading an MSDN article on low-latency audio, and noticed it mentions some improvements in Windows 10:

"Starting in Windows 10 , WASAPI has been enhanced to:

• Allow an application to discover the range of buffer sizes (i.e. periodicity values) that are supported by the audio driver of a given audio device. This makes it possible for an application to choose between the default buffer size (10ms) or a small buffer (<10ms) when opening a stream in shared mode. If an application does not specify a buffer size, then it will use the default buffer size.
• Allow an application to discover the current format and periodicity of the audio engine. This allows applications to snap to the current settings of the audio engine.
• Allow an app to specify that it wishes to render/capture in the format it specifies without any re-sampling by the audio engine

The above features will be available on all Windows devices. However, certain devices with enough resources and updated drivers will provide a better user experience than others.
The above functionality is provided by a new interface, called IAudioClient3, which derives from IAudioClient2."

Could those new features be any use for WinUAE? It could allow sound buffer size setting of 1 to always correspond to the smallest buffer supported by the specific audio driver.

It looks like there's also IAudioClient2::GetBufferSizeLimit which seems to serve a similar purpose? That's supported from Windows 8 on.

[Toni Wilen]

I don't think they will help because buffer size and frequency is already adjustable in UAE. It never asks for some sound driver defaults.

AFAIK It is also difficult to use Win8+ SDK and still create XP compatible executables.

[mark_k]

Knowing the smallest buffer size supported by the hardware driver could be useful, maybe a sound buffer size setting of 0 could be used to indicate that?

I can set buffer size to 1 and still get crackle-free audio, so I'm wondering how much lower could be possible.

[Toni Wilen]

Sounds useful enough. AFAIK lowest supported number of samples is somewhere between 100 and 200 and buffer=1 equals 256 samples.

[Toni Wilen]

I tried AudioClient2 GetBufferSizeLimits() but it only returns AUDCLNT_E_OFFLOAD_MODE_ONLY. Bah.

[Dr.Venom]

Originally Posted by Toni Wilen

I tried AudioClient2 GetBufferSizeLimits() but it only returns AUDCLNT_E_OFFLOAD_MODE_ONLY. Bah.

Does that relate to shared or exclusive mode?

Not sure whether the following may help, but in any case a related problem is mentioned here:

http://stackoverflow.com/questions/3...pi-shared-mode

From reading the last comment from the OP to his own question, the solution seems to be in this part of the MS article

https://msdn.microsoft.com/en-us/lib...surement_Tools

Which says "In order to measure the roundtrip latency for different buffer sizes, users need to install a driver that supports small buffers. The inbox HDAudio driver has been updated to support buffer sizes between 128 samples (2.66ms@48kHz) and 480 samples (10ms@48kHz). The following steps show how to install the inbox HDAudio driver (which is part of all Windows 10 SKUs)"

"After reboot, the system will be using the inbox Microsoft HDAudio driver and not the 3rd-party codec driver. Remember which driver you were using before, so that you can fallback to that driver, if you want to use the optimal settings for your audio codec."

[Toni Wilen]

I added extra path if IAudioClient3 open succeeds, first log current values (GetSharedModeEnginePeriod and GetCurrentSharedModeEnginePeriod), then call InitializeSharedAudioStream (only if shared mode and new buffer size is smaller than default returned by GetSharedModeEnginePeriod). Then log GetSharedModeEnginePeriod values again.

Unfortunately I only get: default=480, min=480, max=480. Returned buffer is also always 1056 samples. (SoundBlaster Z, June 2016 drivers. I also have onboard realtek but it is disabled because last time I tested it, it also installed some useless and broken shell extension..)

Does that relate to shared or exclusive mode?

Neither. Offload is the new mode added in Windows 10, mainly designed for lower power consumption (less data copying). It won't help with latency.

[mark_k]

Try uninstalling the Realtek driver and let Windows install the Microsoft one, maybe that will help with the on-board audio.

[Toni Wilen]

I switched realtek on from bios. Realtek driver does more or less same as SB driver but forced Microsoft HD Audio driver changes Min=128, Max=448. (with Realtek driver Min=448, Max=448)

Hmm.. Now that pull mode is in use, whole WASAPI buffer selection does not make much sense anymore, especially in shared mode where the actual limit is Windows mixer/resampler buffering/latency than emulation and this new InitializeSharedAudioStream() actually adjusts internal mixer/resampler buffer size/timing (which is not visible to application).

Perhaps it is much simpler to always request smallest and lowest latency possible WASAPI buffer and Sound panel buffer selection only adjusts size of WinUAE internal "reservour" buffer.

[mark_k]

A larger-than-minimum WASAPI buffer should help with power saving though, due to less-frequent CPU wakeups? Minimum-possible audio latency isn't always needed. E.g. running a demo, the video latency (double/triple-buffering + LCD monitor latency) could perhaps be larger than the minimum audio latency anyway.

[Toni Wilen]

Powersaving will lose if other choice is better sound stability or latency..

--

I'll try hybrid solution: keep default latency (No calls to InitializeSharedAudioStream) until configured buffer size is about same or lower than DefaultPeriodInFrames and the smaller the buffer, the smaller the PeriodInFrames value gets.

--

btw, InitializeSharedAudioStream documentation is incorrect:

"Periodicity requested by the client. This value must be an integral multiple of the value returned in the pDefaultPeriodInFrames parameter to IAudioClient3::GetSharedModeEnginePeriod. PeriodInFrames must also be greater than or equal to the value returned in pMinPeriodInFrames and less than or equal to the value of returned pMaxPeriodInFrames."

"pDefaultPeriodInFrames" should be "pFundamentalPeriodInFrames".

EDIT: Something done. Also calling IAudioClient2::SetClientProperties(). (If it does something)

[Toni Wilen]

Updated. Now if shared mode and requested buffer size is >= 10ms (Pre-Windows 10 default WASAPI buffer): use normal AudioClient->Initialize(), if < 10ms requested (currently only if buffer 1/2, possibly 3 too or new "min" option), AudioClient3->InitializeSharedAudioStream() is used.

"Min" buffer option added that selects smallest driver supported buffer size.

WASAPI buffer scale adjusted: for example size 5 now is old buffer size 4 and so on. Pull mode is much more stable than push, there is now less need for very big buffers.

It "sounds" like exclusive mode is not really needed anymore unless you want absolutely smallest latency possible.

[Dr.Venom]

Originally Posted by Toni Wilen

Updated. Now if shared mode and requested buffer size is >= 10ms (Pre-Windows 10 default WASAPI buffer): use normal AudioClient->Initialize(), if < 10ms requested (currently only if buffer 1/2, possibly 3 too or new "min" option), AudioClient3->InitializeSharedAudioStream() is used.

"Min" buffer option added that selects smallest driver supported buffer size.

WASAPI buffer scale adjusted: for example size 5 now is old buffer size 4 and so on. Pull mode is much more stable than push, there is now less need for very big buffers.

It "sounds" like exclusive mode is not really needed anymore unless you want absolutely smallest latency possible.

Sounds great. Would love to give this a spin, was winuae.7z already meant to be updated also? (Last one is from last Sunday..)

[Toni Wilen]

Originally Posted by Dr.Venom

Sounds great. Would love to give this a spin, was winuae.7z already meant to be updated also? (Last one is from last Sunday..)

winuae.7z is from yesterday. Perhaps you got cached copy or something?

[Dr.Venom]

Originally Posted by Toni Wilen

winuae.7z is from yesterday. Perhaps you got cached copy or something?

Indeed, I had to empty Firefox cache before it would download the new one. Strange, first time that has happened..

Originally Posted by Toni Wilen

Updated. Now if shared mode and requested buffer size is >= 10ms (Pre-Windows 10 default WASAPI buffer): use normal AudioClient->Initialize(), if < 10ms requested (currently only if buffer 1/2, possibly 3 too or new "min" option), AudioClient3->InitializeSharedAudioStream() is used.

"Min" buffer option added that selects smallest driver supported buffer size.

WASAPI buffer scale adjusted: for example size 5 now is old buffer size 4 and so on. Pull mode is much more stable than push, there is now less need for very big buffers.

It "sounds" like exclusive mode is not really needed anymore unless you want absolutely smallest latency possible.

I just finished a few rounds of testing and this WASAPI implementation is working very very well. For me this is the best version yet. Thanks for putting in the effort for this improvement, much appreciated .

Currently it runs seemingly flawless in low latency vsync mode, i.e. no pull overflows, for the realtek chip (with MS High def driver) with Setting 2 / BUF=352 and for the esi juli@ card with BUF=528 (minimum reported "PeriodInFrames" 480, I guess the card would really need a driver update to support this new Windows 10 Wasapi small buffer feature).

With BUF=352, is it possible to tell what the total latency approximately will be, is it 704/48000=~15ms?

WASAPI: Shared Pull CH=2 FREQ=48000 BUF=352 (704)

[vagrant]

Sound is slightly unstable in pull mode with buffer setting of 1.. I havn't done any beta testing since pull mode was first implemented as have built a new PC - but now using old hardware as dedicated winuae machine, although I have win 10 installed now instead of 7.
Anyway I'd like to try this latest "winuae.7z", where is it? beta11 link was updated?

[emufan]

Originally Posted by ED-209

Sound is slightly unstable in pull mode with buffer setting of 1.. I havn't done any beta testing since pull mode was first implemented as have built a new PC - but now using old hardware as dedicated winuae machine, although I have win 10 installed now instead of 7.
Anyway I'd like to try this latest "winuae.7z", where is it? beta11 link was updated?

http://download.abime.net/winuae/files/b/winuae.7z

[vagrant]

Thanks.
Well I have not tested for very long but wasapi with 'min' buffer seems to run very well.
Although something strange. I played a few whdload games and both exhibit a behaviour where random sounds play too long.. as if stuck on a brief loop. Also I think there is occasionally random sounds being played when they shouldn't.. but need to confirm it.
Perhaps this is new type of anomaly that is produce from having too low buffer set in pull mode?
Anyway will continue to use this version, loving the ultra low input/sound latency

[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

[Toni Wilen]

Originally Posted by Dr.Venom

(minimum reported "PeriodInFrames" 480, I guess the card would really need a driver update to support this new Windows 10 Wasapi small buffer feature).

Yeah, it seems 480 is the "old" default.

With BUF=352, is it possible to tell what the total latency approximately will be, is it 704/48000=~15ms?

WASAPI: Shared Pull CH=2 FREQ=48000 BUF=352 (704)

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.