If I enable support RTAudio notification events in my virtual KS
filter and move buffer position every 7 ms, Win 10 (up to 1803) cannot
maintain a reliable stream in shared mode (tested by MME
applications). Only 5 ms is enough on real hardware, and only 3 ms -
in VMware guest.
In Win 8.1, 5 ms is enough even in the VM. In Win 8 and Win 7, 7
ms period is quite enough even in the VM.
With no notification support, Win 10 is able to maintain reliable
streaming with 7 ms period even in the VM.
All systems create RTAudio buffer of 20 ms with two notifications.
Notification events are reqistered and signaled by the driver at the
middle and the end of the buffer.
Looks like modern Windows releases have problems with notification
event processing.
What should be the period between moving buffer position to maintain
reliable streaming in Win 10? I might use even 1 ms but don't want to
product unnecessary load.
******************
WDMAUDIODEV addresses:
Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
Subscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe
Unsubscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe
Moderator: mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx
URL to WDMAUDIODEV page:
http://www.wdmaudiodev.com/
