1 Topic by outofobscure (edited by outofobscure 2020-04-14 21:14:41)

  • Registered: 2020-04-14
  • Posts: 4

Topic: WASAPI Exclusive Event Mode Buffer Size Issues

Hi,
I'm developing an application that makes use of WASAPI Exclusive Mode with Event Driven callbacks. Everything works as expected but there is a small problem:

On my Fireface UC, if the Buffer Size (Latency) in the Fireface USB Settings Dialog is set too high, the sound is garbled or there is no sound at all. At 88200khz buffer sizes of 128 and lower work perfectly, but all buffer sizes above that have garbled output (whole chunks are missing in the resulting audio).

Now WASAPI let's you query the buffer size, and it reports 265 samples (not 256..) @ 88200khz for an exclusive mode / event driven stream (fixed size), so that's the buffer size i tell WASAPI to use. This does not change, no matter what is selected in the RME settings, so i guess they are unrelated, but it's strange that changing them to lower sizes (128) makes it work... it almost seems as if the RME driver is reading from the wrong parts of the WASAPI buffer if the buffer is too large, or WASAPI writes to the wrong part of the RME buffer...

If i force WASAPI to use 256, 512 or 1024 buffer sizes, and also set that exact size (or lower) in the RME settings, then it also works. The problem is, i don't know what buffer sizes users have set, since WASAPI always reports 265 @ 88100 and 132 @ 44100 and as that is what WASAPI says is the minimal bufer size, i'd like to use those, regardless of what is set in the RME settings.. I would expect the RME driver to handle this internally, take the WASAPI buffer (no matter what size) and be able to fill it's internal buffer (smaller or bigger) correctly even if that's a different size, or am i wrong here?

By the way, this is not specific to my application, i tested other applications in WASAPI Exclusive/Event mode, and they have the same problem.

Any ideas why this is ? I have tested this on a number of other (mostly integrated) soundcards, and none of them have this problem (most don't let you set a buffer size anyway). I also implemented ASIO, no problems at all there of course..

2 Reply by MC

  • MC
  • MC
  • Administrator
  • Offline
  • From: Germany/Thailand
  • Registered: 2007-04-06
  • Posts: 25,440

Re: WASAPI Exclusive Event Mode Buffer Size Issues

All I can say is that our driver is based on Microsoft's IMiniportWaveCyclic driver. WASAPI etc are MS drivers/layers on top of that. We do not provide WASAPI ourself, so we have no way to signal any buffer size directly nor can we influence what your app sees when asking for it.

We are also not aware of any method to communicate the hardware buffer size to higher Microsoft driver and application layers.

Our drivers run best with WDM (WASAPI) at lower buffer sizes of 64 and 128 samples. Higher values often work as well, but on some systems can cause stuttering effects. We are not aware of a way to change this without re-writing the whole driver from scratch - which we won't do.

Regards
Matthias Carstens
RME

MC's Website

3 Reply by outofobscure (edited by outofobscure 2020-04-15 20:30:02)

  • Registered: 2020-04-14
  • Posts: 4

Re: WASAPI Exclusive Event Mode Buffer Size Issues

OK, thanks for your reply, this is what i thought, that the problem is that there is no way to communicate the buffer size to wasapi / windows, so there's really no solution to this i guess, other than to tell users to switch to a lower buffer setting for the rme driver manually... I didn't expect a real solution, but now that i have confirmation at least i can stop trying to make this work more reliable. It's a bit unfortunate, as this is the just the latest in many audio APIs Microsoft messed up in one or another crucial way...

4 Reply by outofobscure (edited by outofobscure 2020-04-15 20:36:57)

  • Registered: 2020-04-14
  • Posts: 4

Re: WASAPI Exclusive Event Mode Buffer Size Issues

With total rewrite you probably mean going from WaveCycle to WaveRT? I looks like those drivers can report a minimum buffer size to windows 10: https://docs.microsoft.com/en-us/window … dfrom=MSDN

"In Windows 10 the driver can express its buffer size capabilities using the DEVPKEY_KsAudio_PacketSize_Constraints device property. This property allows the user to define the absolute minimum buffer size that is supported by the driver, as well as specific buffer size constraints for each signal processing mode (the mode-specific constraints need to be higher than the drivers minimum buffer size, otherwise they are ignored by the audio stack)"

The RME driver currently runs at 10ms even with IAudioClient3 in Shared / Event mode and trying to opt-into this new low latency mode succeeds, but doesn't give lower latency than just regularly initializing it.