Win10 updated WASAPI and added IAudioClient3, a new interface derived from IAudioClient2 which makes it possible to use <10ms buffer sizes with shared (non-exclusive) mode for even lower latency. I.e. you can have low buffer size and hear multiple apps at once. Mumble however does not seem to take advantage of this. I suppose it won't work for everyone, but it might be worth it investigating and implementing for the ones for who it will work and can make use of it.
Information on this and some code samples are available here (Search "The following code snippet shows how a music creation app can operate in the lowest latency setting that is supported by the system."):
They additionally add a GitHub link with some samples.
That page also says:
Also, it is recommended for applications that use WASAPI to also use the Real-Time Work Queue API or the MFCreateMFByteStreamOnStreamEx to create work items and tag them as Audio or Pro Audio [...]
[…] application developers that use WASAPI need to tag their streams with the audio category and whether to use the raw signal processing mode.
Win10 updated WASAPI and added IAudioClient3, a new interface derived from IAudioClient2 which makes it possible to use <10ms buffer sizes with shared (non-exclusive) mode for even lower latency. I.e. you can have low buffer size and hear multiple apps at once. Mumble however does not seem to take advantage of this. I suppose it won't work for everyone, but it might be worth it investigating and implementing for the ones for who it will work and can make use of it.
Information on this and some code samples are available here (Search "The following code snippet shows how a music creation app can operate in the lowest latency setting that is supported by the system."):
https://docs.microsoft.com/en-us/windows-hardware/drivers/audio/low-latency-audio
They additionally add a GitHub link with some samples.
That page also says: