Windows 10 Glitches with Buffer Size less than Windows Audio Engine Periodicity

[aerosplat]

I've recently moved from Win7-64 to Win10-64 (specifically didn't use the word "upgraded"). I'm using SAR 0.13.1 to pipe Windows Sound Mapper audio into Ableton (for VST plugin routing) and then on to my Roland Octa-Capture using the Octa-Capture's native ASIO driver. I want to set the Octa-Capture driver at 1536 samples at 192kHz (A particular VST plugin needs this rate). This buffer size shouldn't create a problem with the default Windows Audio Engine Periodicity of 10ms (1920 samples), but it definitely does have problems (nothing but constant buffer underruns). It "works" (still glitches once in a while) if I set the Octa-Capture driver at 1024 samples or less with glitches increasing with lower buffer sizes, but 1536 samples should only represent 8ms, less than the 10ms Windows default, so I don't understand why I can't use a buffer size larger than 1024 samples.

Under Win7, I could run the Octa-Capture driver at 1536 samples and this SAR->Ableton->Octa-Capture configuration was ROCK SOLID (no glitches whatsoever). It seems like I have to lengthen the Windows Audio Engine Periodicity, but, according to the Microsoft Docs, it defaults to its maximum value of 10ms and I can only make it SHORTER (5ms to 9ms) by incorporating the "PKEY_AudioEngine_OEMPeriod" setting in the SAR driver's Registry information.

Has anyone run into this? Is it possible to set PKEY_AudioEngine_OEMPeriod such that the Windows default buffer is LARGER than 10ms? If I can't figure this out, I'll have to upgrade from Win10 back to Win7.

[eiz]

I can't speak to the rest of your problem at the moment but the system audio engine periodicity cannot be changed upwards from 10ms.

So you're using the exact same buffer sizes between Windows 7/10 and getting glitches only on 10? What Windows 10 version are you on, 1903?

[aerosplat]

Yes; that is correct. The setup worked flawlessly under Win7 and I can't make it stable under Win10. I've tried everything I have found on the web to tighten up Win10 (eliminate unnecessary processes/services, give background processes priority, disable unused devices, etc., etc.); I just can't seem to crack this nut.

[aerosplat]

Oh, and I am using version 1903; sorry for the omission.

[aerosplat]

I'm at the end of my rope. I need the glitch-free audio I was getting with Win7 and I could only achieve this with an ASIO buffer size of 1536 samples at 192kHz. Unfortunately, under Win10, the largest ASIO buffer that works at 192kHz (but still results in periodic glitches) is 1024. Reducing the sample rate simply reduces the sample count that works (e.g. dropping to 96kHz means ASIO buffer size can't be larger than 512 samples without horrible regular glitching).

I'm begging for information here! Why did SAR work perfectly on Win7 with 1536 samples at 192kHz, but won't work with the same buffer size on Win10? Does anyone know how Win10 differs from Win7 regarding how sound data gets from an application through "Microsoft Sound Mapper" to SAR (default device), especially concerning how Windows configures buffer sizes? I've read up on WaveRT and Kernel Streaming and haven't found any acknowledged differences between Win7 and Win10, but do know I'm not alone chasing these Win10 audio glitching problems.

I would be grateful for any information and/or advice in how to use a 1536 sample buffer at 192kHz (or ratio) with SAR under Windows 10? Please!!!!!!!!!!

[aerosplat]

One thing that did occur to me that might ring a bell is this excerpt from a Microsoft discussion of how WaveRT works: In Windows Vista and later operating systems, when the operating system starts and the audio engine is initialized, the audio engine enumerates the KS filters that represent the audio devices. During the enumeration, the audio engine instantiates the drivers for the audio devices that it finds. This process results in the creation of filter objects for these devices. For WaveRT audio devices, the resulting filter object has the following components: An instance of the WaveRT port driver to manage the generic system functions for the filter An instance of the WaveRT miniport driver to handle all the hardware-specific functions of the filter

Windows 10 can drive my Roland Octa-capture just fine with 2048 samples at 192kHz, but not SAR. I'm wondering if it has something to do with the fact that SAR's "virtual sound device" (and associated buffer size) doesn't yet exist at Windows start-up so the above definition of filter objects associated with SAR can't happen like it does with actual sound devices. Apparently, Win7 didn't care about this (or chose a larger default buffer size), but Win10 might care. Thoughts?

[aerosplat]

Oops; I didn't mean to suggest SAR would work at 2048 samples / 192kHz due to the 100ms buffer size limitation, but it SHOULD work at 1536 samples / 192kHz.

[aerosplat]

Man; I'm not batting 1.000. SAR's buffer limit is 10ms, not 100ms. Still, 1536 samples at 192kHz should work. SAR supports it; Windows 7 supports it; Windows 10 doesn't.

[amurzeau]

I'm using Windows 8.1 and ASIO4ALL and tried 1024 samples at 192khz without issues so SAR should works (that should not be too fast for SAR).

When you use Octa-capture ASIO driver directly without SAR from ableton at 1536 sample buffer at 192kHz, do you get glitches ?

[amurzeau]

Also maybe try ableton + SAR on Octa-capture ASIO driver at lower speed like 48khz 256 samples buffer, that should ask for less CPU time

[aerosplat]

I can't speak to the rest of your problem at the moment but the system audio engine periodicity cannot be changed upwards from 10ms.

So you're using the exact same buffer sizes between Windows 7/10 and getting glitches only on 10? What Windows 10 version are you on, 1903?

Apparently, there have been changes between Win7 and Win10 audio buffer sizing discussed here: https://docs.microsoft.com/en-us/windows-hardware/drivers/audio/low-latency-audio

The document is all about "reduced latency". There's not a word in there about NEGATIVE side effects of the changes (why what worked before might not work now), but I was thinking about their specific claim that Win10 allows the device to define its own upstream buffer size unlike previous Windows versions that always used a 10ms buffer. Is it possible that Win10 thinks SAR is asking for a buffer size less than 10ms regardless of what I've chosen within the Octa-capture's ASIO driver? I've also experimented with ASIO4ALL and it also appears to exhibit a maximum stable buffer size under Win10 and it's totally different than what "sort of" works with SAR and my Octa-Capture.

Thoughts?

[aerosplat]

When you use Octa-capture ASIO driver directly without SAR from ableton at 1536 sample buffer at 192kHz, do you get glitches ?

No; that works fine. The Octa-capture supports an ASIO buffer size of 4092 samples at 192kHz and that works fine too. The problem really does appear to be upstream of SAR.

[amurzeau]

And SAR + Octa-capture at 48khz ? Does it works without glitches ?

[aerosplat]

Reducing the sample rate has no impact on stability. At 192kHz, the best I can get is 1024 samples, but with minor glitching. I can't go to 1536 samples without horrendous constant buffer underruns.

Reducing to 96kHz means 512 samples is as high as I can go without underruns, but still periodically glitches. The ratio applies all the way down.

The Octa-capture ASIO driver needs a buffer of at least 8ms to run glitch free, but SAR won't run properly at 8ms, so I'm setting the buffer size at 5.3ms (the next step down). SAR works, but the Octa-capture glitches periodically.

Bottom line: the minimum stable buffer that is glitch free for the Octa-capture is too big for SAR under Win10. In the old days, if you had slow hardware (which I don't), you could compensate be increasing buffer size (and latency), but it seems you can't do that anymore.

[amurzeau]

Can you try this https://github.com/eiz/SynchronousAudioRouter/pull/65#issuecomment-475818284 ? This is the latest SAR driver but it is not signed so it requires testsigning on as explained in the comment.

[aerosplat]

Hmmm... even accommodating the "test"-signed driver, I get this:

[paulheu]

This now broke my SAR install which worked fine before... Unable to get it started again no matter what I try..

[aerosplat]

They say that someone who does something over and over again, expecting different results, is a fool. Well, I tried to install it again after coming home from work and it installed just fine.

I have no explanations. On to testing...

[aerosplat]

Testing completed. With respect to this issue, the test SAR version behaved identically to the previous version. When the ASIO buffer is set to 8ms (1535 samples at 192kHz), it appears (if you believe Win10 works like Microsoft says it does) Windows 10 still thinks SAR wants a buffer smaller than 8ms and continuous underruns occur.

[aerosplat]

https://answers.microsoft.com/en-us/windows/forum/windows_10-hardware/windows-10-changes-to-reduce-audio-latency-legacy/e2406e79-a21f-4b3f-b6ff-784f311c22ad?tm=1564116861199

[aerosplat]

For Mackenzie:

When I choose either the onboard audio or Octa-capture as the default sound output device, everything works fine, even with buffer sizes that appear to be too large when I'm using SAR. Is it possible that SAR is not communicating the selected ASIO buffer size properly to Windows 10?

[aerosplat]

Well, crud. It appears that PKEY_AudioEngine_OEMPeriod, registry {E4870E26-3CC5-4CD2-BA46-CA0A9A70ED04},6 for Win 7 according to MS docs, may not be implemented in Win 10, at least not under that key, so forcing a SAR output device to have an "override" system audio engine periodicity may not be possible.

[aerosplat]

Sir,

Any words on a Win10-specific version of SAR that properly reports the selected ASIO buffer size to the OS? Win10 includes a “variable buffer size” functionality that Win7 didn’t have, but it’s pretty obvious that the latest SAR driver doesn’t interface properly with Win10 so SAR can’t exploit this functionality.

Thanks!

V/r,

-Dale

Dale W. Carter, GS-13, DAF AFSEC/SEFE (MAAF)

From: Mackenzie Straight notifications@github.com Sent: Wednesday, 3 July, 2019 17:30 To: eiz/SynchronousAudioRouter SynchronousAudioRouter@noreply.github.com Cc: aerosplat aerosplat@gmail.com; Author author@noreply.github.com Subject: Re: [eiz/SynchronousAudioRouter] Windows 10 Glitches with Buffer Size less than Windows Audio Engine Periodicity (#74)

I can't speak to the rest of your problem at the moment but the system audio engine periodicity cannot be changed. So you're using the exact same buffer sizes between Windows 7/10 and getting glitches only on 10? What Windows 10 version are you on, 1903? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/eiz/SynchronousAudioRouter/issues/74?email_source=notifications&email_token=AMQSWPGNAGFQ3TO2TE3SNEDP5UZA3A5CNFSM4H5NNW62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZF5THI#issuecomment-508287389 , or mute the thread https://github.com/notifications/unsubscribe-auth/AMQSWPCOSUMQFA3FRJQDKVLP5UZA3ANCNFSM4H5NNW6Q . https://github.com/notifications/beacon/AMQSWPFAB2P67HAKVTRP2GDP5UZA3A5CNFSM4H5NNW62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZF5THI.gif