* 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://blogs.msdn.microsoft.com/matthew_van_eerde/2017/01/09/collecting-audio-logs-the-old-fashioned-way/
________________________________
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>
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of Vincent Burel ;(VB-Audio)
Sent: Mittwoch, 7. Februar 2018 13:48
To: wdmaudiodev@xxxxxxxxxxxxx<mailto: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://docs.microsoft.com/en-us/windows-hardware/drivers/audio/low-latency-audio<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>
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.
