Interesting information about latency in Win10

[matt]

Windows 10 has been enhanced in three areas to reduce latency:

All applications that use audio will see a 4.5-16ms reduction in round-trip latency (as was explained in the section above) without any code changes or driver updates, compared to Windows 8.1. a. Applications that use floating point data will have 16ms lower latency. b. Applications that use integer data will have 4.5ms lower latency.
Systems with updated drivers will provide even lower round-trip latency: a. Drivers can use new DDIs to report the supported sizes of the buffer that is used to transfer data between the OS and the H/W. This means that data transfers do not have to always use 10ms buffers (as they did in previous OS versions). Instead, the driver can specify if it can use small buffers, e.g. 5ms, 3ms, 1ms, etc. b. Applications that require low latency can use new audio APIs (AudioGraph or WASAPI), in order to query the buffer sizes that are supported by the driver and select the one that will be used for the data transfer to/from the H/W.
When an application uses buffer sizes below a certain threshold to render and capture audio, the OS enters a special mode, where it manages its resources in a way that avoids interference between the audio streaming and other subsystems. This will reduce the interruptions in the execution of the audio subsystem and minimize the probability of audio glitches. When the application stops streaming, the OS returns to its normal execution mode. The audio subsystem consists of the following resources: a. The audio engine thread that is processing low latency audio. b. All the threads and interrupts that have been registered by the driver (using the new DDIs that are described in the section about driver resource registration). c. Some or all of the audio threads from the applications that request small buffers, as well as from all applications that share the same audio device graph (e.g. same signal processing mode) with any application that requested small buffers:
AudioGraph callbacks on the streaming path.
If the application uses WASAPI, then only the work items that were submitted to the Real-Time Work Queue API or MFCreateMFByteStreamOnStreamEx and were tagged as "Audio" or "ProAudio".

[mr_es335]

matt,

Can you provide the source...

[John Ludlow]

matt,

Can you provide the source...

It's here, I believe, Dell:

https://docs.microsoft.com/en-us/win...-latency-audio

Very interesting, Matt.

[John Ludlow]

From the link, about a quarter of the way down:

<<<
"3. When an application uses buffer sizes below a certain threshold to render and capture audio, the OS enters a special mode, where it manages its resources in a way that avoids interference between the audio streaming and other subsystems. This will reduce the interruptions in the execution of the audio subsystem and minimize the probability of audio glitches. When the application stops streaming, the OS returns to its normal execution mode. The audio subsystem consists of the following resources: a. The audio engine thread that is processing low latency audio. b. All the threads and interrupts that have been registered by the driver (using the new DDIs that are described in the section about driver resource registration).c. Some or all of the audio threads from the applications that request small buffers, as well as from all applications that share the same audio device graph (e.g. same signal processing mode) with any application that requested small buffers:"
>>>

At first I thought that this was limited to applications in which a single stream is processed and output - like a mono wav stream with a section set aside for processing mid-stream. The scope of glitch protection within the class seems to be limited to particular data streams. But, I presume, at least, that those class streams can also be stacked and inherited - which may allow conferring protection on a process involving multiple simultaneous streams. They'd almost have to since something as simple as a stereo signal is actually multiple streams. It wouldn't be much use without being able to consider them as a single entity.

Also - they don't mention anything about limiting protection to processes occurring within a single core. But they're definitely talking about processes making memory calls (buffers) being protected.

One probably can't know for sure without actually testing it. Still, the prospect of being able to give active SAW and SAC processes (most especially: SAC...) 'critical' status at low latency sounds pretty sweet. Being able to do that across multiple processors would be even better. And, for once, it's only available in the latest version of the OS (Windows 10).

[matt]

One probably can't know for sure without actually testing it. Still, the prospect of being able to give active SAW and SAC processes (most especially: SAC...) 'critical' status at low latency sounds pretty sweet. Being able to do that across multiple processors would be even better. And, for once, it's only available in the latest version of the OS (Windows 10).

This was my thinking when I read the article.

And this:

Before Windows 10, the latency of the Audio Engine was equal to ~12ms for applications that use floating point data and ~6ms for applications that use integer data
In Windows 10, the latency has been reduced to 1.3ms for all applications

https://docs.microsoft.com/en-us/win...-latency-audio

[John Ludlow]

This was my thinking when I read the article.

And this:

Before Windows 10, the latency of the Audio Engine was equal to ~12ms for applications that use floating point data and ~6ms for applications that use integer data
In Windows 10, the latency has been reduced to 1.3ms for all applications

Shows, one more time, how smart Bob was way back then to buck the trend and use integer math rather than floating point.

I imagine that 1.3ms is a best-case, not-real-world, scenario though. Class inheritance of individual 1.3ms streams would probably add up to longer delays in a multi-track. Still - that has always been the case. Starting with 1.3ms streams at the lowest level, rather than 6ms streams, can't do anything but help.

It's the part about the protection covering memory calls that is most interesting to me. Bob has said that this is what has been the downfall of the later versions of Windows for SAC and SAW: increasing numbers of background operating system processes vying for time slices that don't respect the application-defined priority in memory calls across cores. This article seems to indicate that this methodology, built specifically for audio streams, will respect them in that situation. Pretty game-changing. Again though - print is cheap. It looks promising, but we might be misunderstanding - there's wiggle-room there. We won't know until it's actually tested.