12 October 2016, 16:45 | #21 | |
Registered User
Join Date: Mar 2012
Location: Australia
Age: 44
Posts: 1,126
|
Quote:
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) |
|
12 October 2016, 18:38 | #22 |
Registered User
Join Date: Aug 2004
Location:
Posts: 3,335
|
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:
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) Last edited by mark_k; 12 October 2016 at 18:52. |
12 October 2016, 18:59 | #23 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,505
|
Quick hint: try typing something to sound frequency select menu.
EDIT: Ex mode AUDCLNT_E_BUFFER_SIZE_ERROR fixed. |
12 October 2016, 19:09 | #24 |
Registered User
Join Date: Aug 2004
Location:
Posts: 3,335
|
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. Last edited by mark_k; 12 October 2016 at 20:48. |
12 October 2016, 20:34 | #25 |
Registered User
Join Date: Aug 2004
Location:
Posts: 3,335
|
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.) Last edited by mark_k; 12 October 2016 at 20:42. |
12 October 2016, 20:40 | #26 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,505
|
|
13 October 2016, 14:13 | #27 | |
Registered User
Join Date: Aug 2004
Location:
Posts: 3,335
|
Quote:
|
|
13 October 2016, 14:33 | #28 |
Registered User
Join Date: Aug 2004
Location:
Posts: 3,335
|
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. Last edited by mark_k; 13 October 2016 at 14:39. |
13 October 2016, 16:43 | #29 | |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,505
|
Quote:
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. |
|
13 October 2016, 19:54 | #30 |
Registered User
Join Date: Aug 2004
Location:
Posts: 3,335
|
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). |
13 October 2016, 20:46 | #31 | ||
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,505
|
Quote:
EDIT: AUDCLNT_E_RESOURCES_INVALIDATED now does same as AUDCLNT_E_DEVICE_INVALIDATED = re-open the device. Quote:
Last edited by Toni Wilen; 13 October 2016 at 22:25. |
||
13 October 2016, 23:32 | #32 |
Registered User
Join Date: Jul 2008
Location: Netherlands
Posts: 485
|
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: Code:
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] 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? Last edited by Dr.Venom; 15 May 2019 at 20:31. |
14 October 2016, 15:04 | #33 | |
Registered User
Join Date: Jul 2008
Location: Netherlands
Posts: 485
|
Quote:
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..) |
|
14 October 2016, 17:53 | #34 | |
Registered User
Join Date: Aug 2004
Location:
Posts: 3,335
|
Quote:
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. |
|
14 October 2016, 19:40 | #35 |
Registered User
Join Date: Aug 2004
Location:
Posts: 3,335
|
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(): Code:
if (workprefs.sound_freq > 96000) workprefs.sound_freq = 96000; Last edited by mark_k; 14 October 2016 at 20:07. |
14 October 2016, 19:51 | #36 | ||
Registered User
Join Date: Jul 2008
Location: Netherlands
Posts: 485
|
Quote:
Quote:
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. |
||
14 October 2016, 21:57 | #37 | |
Registered User
Join Date: Aug 2004
Location:
Posts: 3,335
|
Extracts from the MSDN IAudioClient::Initialize page, with emphasis added:
Quote:
|
|
17 October 2016, 17:41 | #38 | |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,505
|
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)
Quote:
And why would then Windows 10 support even smaller buffers if above is true? Or "rendering stream" means something different.. |
|
18 October 2016, 13:35 | #39 | |
Registered User
Join Date: Jul 2008
Location: Netherlands
Posts: 485
|
Quote:
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. |
|
20 October 2016, 20:06 | #40 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,505
|
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. |
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 |
|
|