Hello,
I’m afraid the loop is not closed.
First because the use of VirtualLock is not usual and we found no-one in audio
or video game industry using this API
(for example Audio driver interfaces are not using Virtual Locked memory).
Secondly because our test with VirtualLock shown that this is not applicable in
a complex application like Audio DAW or Video Game , involving several GB of
memory in its real time process.
Thirdly, we suspect WIN10 to be able to generate this page fault issue also on
global memory (and all memory allocated by “new” operator).
For those who want to validate the next possible WIN10 Update (expected to fix
this), we invite you to use our minimal stress test program there:
https://forum.vb-audio.com/viewtopic.php?f=11 ;
<https://forum.vb-audio.com/viewtopic.php?f=11&t=519> &t=519
where you also will find source code to use VirtualAlloc / VirtualLock API
Regards
Vincent Burel
De : wdmaudiodev-bounce@xxxxxxxxxxxxx [mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] ;
De la part de Matthew van Eerde (Redacted sender "Matthew.van.Eerde" for DMARC)
Envoyé : mercredi 14 février 2018 10:43
À : wdmaudiodev@xxxxxxxxxxxxx
Objet : [wdmaudiodev] Re: WIN10 Major Issue for Audio Processing (but page
fault is not detected)
Closing the loop – after looking at the second trace, no evidence of multiple
problems, this is the same page fault issue.
There have been changes in RS4 to make this particular page fault issue less
common; you can try out an RS4 preview build by registering on
http://insider.windows.com
I will also point out Larry Osterman’s advice in this other thread in the
Windows Desktop Pro Audio Application Development forum:
https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/8070b2d9-59eb-42bb-8df6-4074276540ab/pro-audio-in-vistawindows?forum=windowspro-audiodevelopment
Ø To prevent audio samples from being paged out, use the VirtualLock API to
lock the pages containing the samples (and the code that you use to render the
samples).
Larry Osterman is a Windows dev who worked on the original implementation of
WASAPI; he has several audio posts on his blog
https://blogs.msdn.microsoft.com/larryosterman/
_____
From: <mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
wdmaudiodev-bounce@xxxxxxxxxxxxx < <mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
wdmaudiodev-bounce@xxxxxxxxxxxxx> on behalf of Matthew van Eerde <
<mailto:dmarc-noreply@xxxxxxxxxxxxx> dmarc-noreply@xxxxxxxxxxxxx>
Sent: Tuesday, February 13, 2018 12:18:17 PM
To: <mailto:wdmaudiodev@xxxxxxxxxxxxx> wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Re: WIN10 Major Issue for Audio Processing (but page
fault is not detected)
Maybe there are multiple different problems then.
_____
From: <mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
wdmaudiodev-bounce@xxxxxxxxxxxxx < <mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
wdmaudiodev-bounce@xxxxxxxxxxxxx> on behalf of Vincent Burel (VB-Audio) <
<mailto:vincent.burel@xxxxxxxxxxxx> vincent.burel@xxxxxxxxxxxx>
Sent: Tuesday, February 13, 2018 12:41:57 AM
To: <mailto:wdmaudiodev@xxxxxxxxxxxxx> wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Re: WIN10 Major Issue for Audio Processing (but page
fault is not detected)
However, the strange point is that no page fault are detected by resource
monitor on our application.
Even the global page fault graph shows a decreasing curve on the DSP peak.
See attached picture.
De : wdmaudiodev-bounce@xxxxxxxxxxxxx [mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] ;
De la part de Vincent Burel (VB-Audio)
Envoyé : mardi 13 février 2018 09:13
À : wdmaudiodev@xxxxxxxxxxxxx
Objet : [wdmaudiodev] Re: WIN10 Major Issue for Audio Processing (page fault
without virtual memory)
Matthew,
Just reproduced the same problem without virtual memory (in a WASAPI Render
Thread - realtek speaker).
We got a peak at 2260% !!! nice one ! on 14 min 51 seconds
(it makes an interruption of 200ms in a process usually performed in less than
0.1 ms !! )
Report and video capture in feedback HUB:
https://aka.ms/Yifjhs ;
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2FYifjhs&data=04%7C01%7CMatthew.van.Eerde%40microsoft.com%7C67beea0cbec74b58901f08d572bdb7a7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636541081578913419%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=4foVScPJbOz275lGLZN0VVL3hT6TRIuqmfDRc9wcdn0%3D&reserved=0>
I don’t know if you will see on the capture, the resource monitor showing page
fault level before and after the peak.
It seems WIN10 memory management has been changed to produce page fault
interruptions and/or massive cache failure…
Regards
Vincent Burel
De : wdmaudiodev-bounce@xxxxxxxxxxxxx [mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] ;
De la part de Matthew van Eerde (Redacted sender "Matthew.van.Eerde" for DMARC)
Envoyé : lundi 12 février 2018 17:44
À : wdmaudiodev@xxxxxxxxxxxxx
Objet : [wdmaudiodev] Re: WIN10 Major Issue for Audio Processing (OS special
mode for small buffer)
Thanks, this trace has Microsoft.Windows.Audio.KernelStreamingEndpoint/Glitch
events, which gives me a place to start looking. I’ll see what I can find.
_____
From: <mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
wdmaudiodev-bounce@xxxxxxxxxxxxx < <mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
wdmaudiodev-bounce@xxxxxxxxxxxxx> on behalf of Vincent Burel (VB-Audio) <
<mailto:vincent.burel@xxxxxxxxxxxx> vincent.burel@xxxxxxxxxxxx>
Sent: Saturday, February 10, 2018 5:11:03 AM
To: <mailto:wdmaudiodev@xxxxxxxxxxxxx> wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Re: WIN10 Major Issue for Audio Processing (OS special
mode for small buffer)
Matthew,
Just reproduced the problem with a WASAPI Render Thread (realtek speaker)
instead of ASIO Callback.
We measure a simple 128 channels BUS copy operation in a 512 samples 44100 Hz
audio stream (DSP LOAD < 1% = < 0.1 ms processing time)
We got a 204% DSP PEAK in 5 minutes.
It means we have been interrupted during 23.7 ms !!!
Report and video capture in feedback HUB:
https://aka.ms/ ;
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2FFtocxe&data=04%7C01%7CMatthew.van.Eerde%40microsoft.com%7C34a38985ab5f4f2b8e4f08d57087cd85%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C1%7C636538650949482857%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=mBTP5HX4%2Br2raPjo3hDv%2FbL4QsZYL8vQ31Rx91p8rOg%3D&reserved=0>
Ftocxe
REM: if we launch our ASIOtest application 2 or 3 times, one with a realtek
audio device (WASAPI), the other with other devices (ASIO) in 32 or 64bits. We
got the DSP peak basically in the same time in 3 applications but with
different DSP PEAK – see attached picture, one is 180% , other is 178% and the
third is below 80% (our threshold to detect incident) but we can see it above
50 on the graph.
Regards
Vincent Burel
De : <mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
wdmaudiodev-bounce@xxxxxxxxxxxxx [ <mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] De la part de Matthew van Eerde ;
(Redacted sender "Matthew.van.Eerde" for DMARC)
Envoyé : jeudi 8 février 2018 18:18
À : <mailto:wdmaudiodev@xxxxxxxxxxxxx> wdmaudiodev@xxxxxxxxxxxxx
Objet : [wdmaudiodev] Re: WIN10 Major Issue for Audio Processing (OS special
mode for small buffer)
Thanks, we’ll take a look.
_____
From: <mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
wdmaudiodev-bounce@xxxxxxxxxxxxx < <mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
wdmaudiodev-bounce@xxxxxxxxxxxxx> on behalf of Vincent Burel (VB-Audio) <
<mailto:vincent.burel@xxxxxxxxxxxx> vincent.burel@xxxxxxxxxxxx>
Sent: Thursday, February 8, 2018 7:25:20 AM
To: <mailto:wdmaudiodev@xxxxxxxxxxxxx> wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Re: WIN10 Major Issue for Audio Processing (OS special
mode for small buffer)
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2FJuqede&data=04%7C01%7CMatthew.van.Eerde%40microsoft.com%7C34a38985ab5f4f2b8e4f08d57087cd85%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C1%7C636538650949482857%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=vrWEIdx6UHvJqsJg0KefN03Rs180WWQSiWjLNRBlpac%3D&reserved=0>
https://aka.ms/Juqede
De : <mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
wdmaudiodev-bounce@xxxxxxxxxxxxx [ <mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] De la part de Matthew van Eerde ;
(Redacted sender "Matthew.van.Eerde" for DMARC)
Envoyé : jeudi 8 février 2018 14:53
À : <mailto:wdmaudiodev@xxxxxxxxxxxxx> wdmaudiodev@xxxxxxxxxxxxx
Objet : [wdmaudiodev] Re: WIN10 Major Issue for Audio Processing (OS special
mode for small buffer)
Thanks. Can you grab a direct aka.ms/… link from Feedback Hub / Feedback / My
feedback / (click the problem report) / Share and send it to me?
_____
From: wdmaudiodev-bounce@xxxxxxxxxxxxx <wdmaudiodev-bounce@xxxxxxxxxxxxx> on
behalf of Vincent Burel (VB-Audio) <vincent.burel@xxxxxxxxxxxx>
Sent: Wednesday, February 7, 2018 11:59:37 PM
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Re: WIN10 Major Issue for Audio Processing (OS special
mode for small buffer)
Matthew,
Just reproduced the problem and submit in feedback hub.
“Audio Stream Cut”.
Regards
Vincent Burel
De : wdmaudiodev-bounce@xxxxxxxxxxxxx [mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] ;
De la part de Matthew van Eerde (Redacted sender "Matthew.van.Eerde" for DMARC)
Envoyé : mercredi 7 février 2018 18:49
À : wdmaudiodev@xxxxxxxxxxxxx
Objet : [wdmaudiodev] Re: WIN10 Major Issue for Audio Processing (OS special
mode for small buffer)
Ø an audio thread, in TIME_CRITICAL mode, with the right AUDIO MMCSS attribute
Please take “audio glitch” traces of this and send them to me; I want to see
what’s doing the pre-empting.
https://blogs.msdn.microsoft.com/matthew_van_eerde/2016/09/26/report-problems-with-logs-and-suggest-features-with-the-feedback-hub/
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblogs.msdn.microsoft.com%2Fmatthew_van_eerde%2F2016%2F09%2F26%2Freport-problems-with-logs-and-suggest-features-with-the-feedback-hub%2F&data=04%7C01%7CMatthew.van.Eerde%40microsoft.com%7C03322033bdb345d9fbc908d56eca0255%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636536736288898788%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=Wy6gRozvmu7nNm0YuSoK8MY4X1lNoa%2BpnLzXRN25WZY%3D&reserved=0>
https://blogs.msdn.microsoft.com/matthew_van_eerde/2017/01/09/collecting-audio-logs-the-old-fashioned-way/
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblogs.msdn.microsoft.com%2Fmatthew_van_eerde%2F2017%2F01%2F09%2Fcollecting-audio-logs-the-old-fashioned-way%2F&data=04%7C01%7CMatthew.van.Eerde%40microsoft.com%7C03322033bdb345d9fbc908d56eca0255%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636536736288898788%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=HqQpYhOSw13Lpse8NyjysZN0i0D0r2d6APqD5z6dQNk%3D&reserved=0>
_____
From: wdmaudiodev-bounce@xxxxxxxxxxxxx <wdmaudiodev-bounce@xxxxxxxxxxxxx> on
behalf of Vincent Burel (VB-Audio) <vincent.burel@xxxxxxxxxxxx>
Sent: Wednesday, February 7, 2018 9:46:14 AM
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Re: WIN10 Major Issue for Audio Processing (OS special
mode for small buffer)
It is all audio related (WASAPI as well),
With the example I gave, an audio thread, in TIME_CRITICAL mode, with the right
AUDIO MMCSS attribute
Can be pre-empted for 10, 20ms… or more.
De : wdmaudiodev-bounce@xxxxxxxxxxxxx [mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] ;
De la part de Support HpW-Works.com
Envoyé : mercredi 7 février 2018 17:00
À : wdmaudiodev@xxxxxxxxxxxxx
Objet : [wdmaudiodev] Re: WIN10 Major Issue for Audio Processing (OS special
mode for small buffer)
Hi Vincent,
As it looks as ASIO, it is not WASAPI or MS Audio related. In other words may a
USB HW driver compatibility issue how packages are deliverd.
Have the same issue on a Win 7 & RENESAS-USB3 (HW & 4er Port) using latest
Thesycon drivers, where on Win 10 works as a charm.
Testing bits is may one way, using a spectrum, you would see it soon
graphically 😃
Best Regards
Hp. Widmer
HpW-Works Support
Mailto:support@xxxxxxxxxxxxx
Website: http://www.hpw-works.com ;
<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.hpw-works.com&data=04%7C01%7CMatthew.van.Eerde%40microsoft.com%7Cba53e41adee041393d1308d56e52c1c1%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C1%7C636536224127715959%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=HqgDvFdXKenVGf7QTME51ypPuyGWuQjmw8bZUqmJ%2BuI%3D&reserved=0>
From: wdmaudiodev-bounce@xxxxxxxxxxxxx
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of Vincent Burel ;(VB-Audio)
Sent: Mittwoch, 7. Februar 2018 13:48
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] WIN10 Major Issue for Audio Processing (OS special mode
for small buffer)
Hello,
While we were trying to validate our MT128 application on WIN10 …
We have detected unexpected DSP Peaks in ASIO Callback showing that the audio
processing Is not in the right priority with Windows 10
(peaks are above 100% while the average DSP load is below 10% - the problem
does not exist on WIN7 or XP)
Consequently: continuous and reliable audio stream under win10 are not possible.
The only explanation we found is given by this brilliant idea:
Audio Stack Improvements in Windows 10
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
REF :
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows-hardware%2Fdrivers%2Faudio%2Flow-latency-audio&data=04%7C01%7CMatthew.van.Eerde%40microsoft.com%7Cba53e41adee041393d1308d56e52c1c1%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636536224127715959%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=NkIwvqcuxHt1L0r2WV%2FWq3U744IXhYO4kKa1gGnmf5c%3D&reserved=0>
https://docs.microsoft.com/en-us/windows-hardware/drivers/audio/low-latency-audio
It seems it also works in the other way:
when the O/S detects that we are dealing with a big buffer (e.g. 32 times the
audio buffer size), the OS exits from the special mode and we can be
pre-empted.
The problem is that when managing 128 I/O or 128 Tracks or any optimized Matrix
or Patch with hundreds buffers in internal busses, we often work with optimized
memory organization to avoid or limit CACHE FAILURE. Then 32, 128 or 512 small
buffers can be converted, processed, moved or copied in a continuous address
range, that WIN10 O/S will interpret as “big buffer” processing…
Example of code making appear the DSP PEAK in ASIO Callback:
Let’s imagine 2x 128 channels BUS (single allocation per bus – all initialized
to zero):
nbByte = nbSamplePerBuffer * 4;//(to simulate float32 samples)
char * lpSource = malloc(nbByte *128);//128 channels BUS
char * lpTarget = malloc(nbByte *128);//128 channels BUS
memset(lpSource, 0, nbByte *128); //set all to zero
memset(lpTarget, 0, nbByte *128); //set all to zero
To copy these 128 buffer in a continuous address range will produce DSP peak
for (n=0; n<128; n++)
{
memcpy(lpTarget, lpSource , nbByte);
lptarget+=nbByte;
lpSource+=nbByte;
}
Note this 128 copy single buffer to multi buffer produces a DSP peak as well
for (n=0; n<128; n++)
{
memcpy(lpTarget, lpSource , nbByte);
lptarget+=nbByte;
}
REM1: The problem does not belong to memcpy function, we tested different ways
to copy or process (including direct ASM, 32 or 64bits, compiled with VC6 or
VC2010).
REM2: DSP peak(s) incident come in the first 20 minutes, and can generate no
peak for 24hours...
The questions are:
Ø Does anyone have experience on this problem, and possible workaround ?
Ø how to disable this “Audio Stack Improvement”’? or change the “Threshold” to
1MB for example?
Regards
Vincent Burel
PS: we have an ASIO validation process in our MT128 Application Series able to
detect any DSP peak and different instability in the stream (www.mt128.com
<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.mt128.com&data=04%7C01%7CMatthew.van.Eerde%40microsoft.com%7Cba53e41adee041393d1308d56e52c1c1%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C1%7C636536224127715959%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=LN3R92zRobTmrHbuvimOYrUzCSrX8w57yxEjsHMdA8Y%3D&reserved=0>
) but we also developed a complete ASIO Tester application to isolate the
problem and get more precision (see attached picture).
Our tests have been performed with 5 different WIN10 PC’s and different audio
boards (RME MADI FX, Yamaha Dante, Focusrite Saffire 6 USB, Steinberg UR22MKII
USB, Tascam US16x08 USB). DSP peak is usually appearing in less than 30 minutes
after having launched the application.
