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://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) 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.
Attachment:
TascamUS16x08_44100_256smp_64bitsASIO.gif
Description: GIF image
