[wdmaudiodev] Re: WIN10 Major Issue for Audio Processing (OS special mode for small buffer)

  • From: "Vincent Burel \(VB-Audio\)" <vincent.burel@xxxxxxxxxxxx>
  • To: <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Thu, 8 Feb 2018 08:59:37 +0100

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://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] 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.

 

 

Other related posts: