English Amiga Board Amiga Lore


Go Back   English Amiga Board > Support > support.WinUAE

 
 
Thread Tools
Old 30 August 2016, 18:19   #1
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,480
WASAPI audio on Windows 10

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.
mark_k is offline  
AdSense AdSense  
Old 30 August 2016, 19:03   #2
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,531
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.
Toni Wilen is offline  
Old 06 September 2016, 09:35   #3
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,480
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.
mark_k is offline  
Old 06 September 2016, 11:29   #4
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,531
Sounds useful enough. AFAIK lowest supported number of samples is somewhere between 100 and 200 and buffer=1 equals 256 samples.
Toni Wilen is offline  
Old 09 October 2016, 13:31   #5
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,531
I tried AudioClient2 GetBufferSizeLimits() but it only returns AUDCLNT_E_OFFLOAD_MODE_ONLY. Bah.
Toni Wilen is offline  
Old 09 October 2016, 15:40   #6
Dr.Venom
Registered User
 
Join Date: Jul 2008
Location: Netherlands
Posts: 281
Quote:
Originally Posted by Toni Wilen View Post
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."
Dr.Venom is offline  
Old 09 October 2016, 17:32   #7
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,531
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..)

Quote:
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.

Last edited by Toni Wilen; 09 October 2016 at 18:04.
Toni Wilen is offline  
Old 09 October 2016, 18:03   #8
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,480
Try uninstalling the Realtek driver and let Windows install the Microsoft one, maybe that will help with the on-board audio.
mark_k is offline  
Old 09 October 2016, 20:06   #9
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,531
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.
Toni Wilen is offline  
Old 09 October 2016, 20:27   #10
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,480
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.
mark_k is offline  
Old 09 October 2016, 21:52   #11
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,531
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)

Last edited by Toni Wilen; 09 October 2016 at 22:01.
Toni Wilen is offline  
Old 10 October 2016, 16:25   #12
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,531
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.
Toni Wilen is offline  
Old 11 October 2016, 13:56   #13
Dr.Venom
Registered User
 
Join Date: Jul 2008
Location: Netherlands
Posts: 281
Quote:
Originally Posted by Toni Wilen View Post
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..)
Dr.Venom is offline  
Old 11 October 2016, 15:31   #14
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,531
Quote:
Originally Posted by Dr.Venom View Post
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?
Toni Wilen is offline  
Old 11 October 2016, 23:49   #15
Dr.Venom
Registered User
 
Join Date: Jul 2008
Location: Netherlands
Posts: 281
Quote:
Originally Posted by Toni Wilen View Post
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..

Quote:
Originally Posted by Toni Wilen View Post
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)
Dr.Venom is offline  
Old 12 October 2016, 09:21   #16
ED-209
Registered User

ED-209's Avatar
 
Join Date: Mar 2012
Location: OCP
Age: 37
Posts: 960
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?
ED-209 is offline  
Old 12 October 2016, 09:41   #17
emufan
Registered User
 
Join Date: Feb 2012
Location: #DrainTheSwamp
Posts: 3,626
Quote:
Originally Posted by ED-209 View Post
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
emufan is offline  
Old 12 October 2016, 11:45   #18
ED-209
Registered User

ED-209's Avatar
 
Join Date: Mar 2012
Location: OCP
Age: 37
Posts: 960
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
ED-209 is offline  
Old 12 October 2016, 12:20   #19
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,531
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 is offline  
Old 12 October 2016, 15:11   #20
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,531
Quote:
Originally Posted by Dr.Venom View Post
(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.

Quote:
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.
Toni Wilen is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Noise when dragging emulation window with WASAPI EX sound mark_k support.WinUAE 0 22 August 2016 20:59
Best Audio Config in Winuae for a Creative X-Fi Audio Card shaf support.WinUAE 2 14 June 2012 16:27
winuae 1.6.1 in Windows 7 and WASAPI audio Gaula92 support.WinUAE 12 13 July 2009 09:14
Crash using Portaudio WASAPI mode Ian support.WinUAE 6 31 May 2009 03:34
cd audio SexyWayne support.Hardware 4 04 May 2005 01:47

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 00:40.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.22911 seconds with 12 queries