Windows Audio (Low latency mode)

Hi,

I’m trying the new “Low Latency Mode” of Windows Audio with juce 6.0.3. What surprises me (and I guess will cause some questions from my users) is that the low latency mode only suggests a buffer size of 480 on my realtek audio device, while both the shared and exclusive flavours of Windows Audio allow me to select 192 samples (and it works fine with that setting, although I have not checked if the actual latency is really lower than the “Low Latency Mode”).

2 Likes

WASAPI low latency mode will directly query the driver for its supported buffer sizes so it sounds like it could be a driver issue, are your realtek drivers up to date? Do you see lower buffer sizes when selecting a different device?

The drivers are up-to-date. I have also tested with a yamaha audio interface, and it is also showing 441 (at 44100kHz) as the sole buffer size availablein “low latency” mode. I did not feel that the latency was lower than with the ‘basic’ Windows Audio. On the realtek, the Latency tester of the juce DemoRunner measures the same latency on “Windows Audio” and “Windows Audio (low latency)”. Also the latency reported when using a buffer size of 192 instead of 480 with “Windows Audio” does not change.

Anyway, it is not a big deal, I was just wondering if my setup is a exception or if “low latency” on windows is 480 samples at 48kHz for most people.

I see the same problem with my PreSonus Studio 18|10 usb. I am also using the latest drivers from PreSonus. Here are my results when initializing the device manager with each variant of Windows Audio:

Device Type: Windows Audio
Input Device: Line In 7/8 (Studio 1810)
Output Device: Line Out 3/4 (Studio 1810)
Sample Rate: 44100.0
Buffer Size: 256
Input Channels: 00000011
Output Channels: 00000011
Current Device: type=‘Windows Audio’ name=‘Line Out 3/4 (Studio 1810)’
Available Buffer Sizes: [132] [160] [192] [224] [256] [288] [320] [352] [384] [416] [441] [448] [480] [512] [576] [640] [704] [768] [832] [896] [960] [1024] [1152] [1280] [1408] [1536] [1664] [1792] [1920] [2048]
Available Sample Rates: [44100.0]

Device Type: Windows Audio (Exclusive Mode)
Input Device: Line In 7/8 (Studio 1810)
Output Device: Line Out 3/4 (Studio 1810)
Sample Rate: 44100.0
Buffer Size: 256
Input Channels: 00000011
Output Channels: 00000011
Current Device: type=‘Windows Audio (Exclusive Mode)’ name=‘Line Out 3/4 (Studio 1810)’
Available Buffer Sizes: [132] [160] [192] [224] [256] [288] [320] [352] [384] [416] [441] [448] [480] [512] [576] [640] [704] [768] [832] [896] [960] [1024] [1152] [1280] [1408] [1536] [1664] [1792] [1920] [2048]
Available Sample Rates: [44100.0] [48000.0]

Device Type: Windows Audio (Low Latency Mode)
Input Device: Line In 7/8 (Studio 1810)
Output Device: Line Out 3/4 (Studio 1810)
Sample Rate: 44100.0
Buffer Size: 441
Input Channels: 00000011
Output Channels: 00000011
Current Device: type=‘Windows Audio (Low Latency Mode)’ name=‘Line Out 3/4 (Studio 1810)’
Available Buffer Sizes: [441]
Available Sample Rates: [44100.0]

Based upon more testing and running Juce DemoRunner in a debugger, I do not believe this is a problem with Juce. When Juce initializes the new WASAPI IAudioClient3 devices, it queries using IAudioClient3::GetSharedModeEnginePeriod for the min, fundemental, max, and default buffer sizes. All of these values come back as 10ms (bufferSize=441 for 44100Hz and 480 for 48000Hz). As far as I can tell, this is a limitation of the drivers on my system. It is counterintuitive because these same devices support 256 buffer size for WASAPI Regular and Exclusive Mode.

Running a utility called REAL.exe, I was able to confirm that even this low latency setup utility reports the same mix, max, and default buffer sizes of 441/480 for my devices.