Complete Windows stalls when using Reaper (DAW software).

[Timur_Born]

The CPU stress stalls that some people (including me) experience with stress tests are even worse than I thought. Up to now I mostly only put time into learning about Ryzen's general operation, compatibility and overclocking, but now I checked DAWBench in Reaper (BIOS 9920).

Turns out that even a single logical core being fully (over)utilized by Reaper leads to extreme system stalls close to making it unusable. That's 15 logical cores being unused and you still can watch graphic elements being built up from top to bottom and input (keyboard/mouse) being heavily broken. Even processes set to run at Realtime (31) priority get interrupted, all the while neither DPC or interrupt latencies can be measured to increase.

I uninstalled HWinfo and did not run any other software that reads out temps and such. On top of that I did a Clear CMOS and replaced the NVidia GPU driver with the Microsoft standard one. I tried various CPU core affinities and power schemes, different memory frequency and timing settings, all to no avail. My 16 thread CPU is literally turned into a 1 thread CPU for this kind of workload.

This also happens in Safe Mode and without using an actual audio driver (null device). It's worse than what I have seen from running ITB and ITB can even run smoothly without stalls under the same circumstances. To make sure that this is not an issue of Reaper (DAW software) I ran my test on an 8 year old 4-threads laptop and there it worked as expected, aka the software stalled when the core was overutilized while the rest of Windows remained usable.

[Timur_Born]

Here is how to replicate this:

- Run some CPU monitor software that allows you to monitor single CPU cores, this makes things easier. HWinfo is a useful example.
- Run Reaper on a single core using its own "Dummy Audio" device at 256 samples. You can set up core affinity in Reaper's own preferences or just use Task-Manager.
- Load "Dawbench-DSP-R5-RXC-EXT".
- Delete tracks Sine 02-40.
- Enable all 8 FX tracks on Sine 01.
- Start playback.
- Duplicate Sine 01 until the one core is nearly at 100% (about 3% total CPU load for 32 logical cores).
- Duplicate Sine 01 once more to overload the single core.

[Timur_Born]

Reaper download page: https://www.reaper.fm/download.php
DAWbench (Reaper project file) download link: http://www.dawbench.com/downloads/dawbench-dsp-2017.zip

[panni]

I'm using reaper as my main sound distribution system. So far everything runs great, I had to uninstall the additional sound software supplied with ASUS's driver package, though. It seems to add ASIO stuff itself.

I didn't run DAWBench yet. Which audio driver and reaper version are you using?

[Timur_Born]

Latest Reaper version download. Tested RME UFX (USB), Fireface 800 (FW) and "Dummy Audio" (a null driver without output offered by Reaper). The latter of which also offers to run the whole thing in Windows' Safe Mode, same results. All Asus software has been uninstalled, which requires manual work, because the Asus uninstaller leaves everything up and running.

It's important to note that this is not an issue of DPC or interrupt latencies, at least not measurably. It's the same kind of full PC stalls that some users report for running some stress tests (ITB/Linpack is one example).

[panni]

OK, interesting. I've noticed that hang-behaviour on OCCT/linpack+AVX and I was under the assumption that was normal.

Then I'm really not of much help here; I can try your test case though. Btw I'm on current REAPER beta (5.50rc13)

Edit: Asked a friend. He doesn't have the freeze-issues with linpack+AVX on his ASUS PRIME X370-Pro, so this may be C6H related?

[panni]

Does the issue still exist in beta bios 1501?

[PeZzy]

panni wrote:
OK, interesting. I've noticed that hang-behaviour on OCCT/linpack+AVX and I was under the assumption that was normal.

Then I'm really not of much help here; I can try your test case though. Btw I'm on current REAPER beta (5.50rc13)

Edit: Asked a friend. He doesn't have the freeze-issues with linpack+AVX on his ASUS PRIME X370-Pro, so this may be C6H related?

Oddly enough the GFlops on the Prime are considerably slower.

Could the problem with the Reaper software be related to the CPU problem which is causing segmentation faults in Linux?

What AMD chipset drivers are you using?

[Timur_Born]

In order to get rid of stalls I tried pulling the battery. Several minutes was not enough, but two hours did the trick. Curiously I was greeted with constant code 0D afterwards until I used the safe boot button (clear settings likely would have done the trick, too). So whatever defaults the board returns to after an empty battery, it doesn't like to boot my B die dimms.

Also switched from 9920 to 1501, did another Clear CMOS and optimized defaults, switched dimms to other slots, all to no avail. One core overload of Reaper + DAWBench stills stalls the whole system.

[Timur_Born]

Well, I took a much closer look at those "freezes" again, which I called stalls, but they are the same thing for what we talk about. Both the GUI/graphic output and keyboard/mouse input are suspended anywhere between a short blip and several seconds (I measured up to around 4). Additionally some but not all processing seems to stop during that time, which I reported wrongly before when I claimed that the whole system stops.

First of all, both the suspension of graphic output and the partly ongoing of background processing can be measured! It's important to note that time-counters seem to roll on regardless of any stalls, which in turn allows software to keep measuring average CPU load, CPU cycles (+delta) and context switches (+delta) and frames per second. The CPU cycles Delta is especially interesting, because it tells us whether a program interrupts processing during a stall or not.

What Delta means is that when you measure over the span of a second then the Delta is the amount of cycles that happened during that second. If a program interrupted its processing during a stall then the CPU cycles Delta decreases on the very next tick right after a stall. If a program kept processing uninterrupted then the Delta increases on the very next tick right after the stall.

Programs that interrupt their processing include: WinRar, 7-Zip, Foobar2000, Firefox (Youtube HTML video output), Furmark
Programs that do not interrupt their processing include: Ableton Live, MediaPlayerClassic, HWinfo

Both WinRar's and 7-Zip's benchmark throughput drop considerably during stalls. WinRar seems to especially dislike my Reaper based workload, or rather the other way around, as WinRar interrupts Reaper even more.

Audio and Video are two very special cases that justify some extra explanation.

Audio:

Audio drivers do not stall, regardless of the audio buffer size being used. I ran a RME Babyface USB ASIO drivers (isochronous USB transfer) at less than 2 ms buffer size without interruption whatsoever while my mouse kept stalling over the very same USB port + hub. If the application keeps processing data (Ableton Live) you can run input audio from the USB audio interface to the application and then back to the audio interface completely uninterrupted while the rest of your system is nearly unusable.

If the application does interrupt its processing during a stall then the size of the application's own audio buffer decides over whether your audio stream gets interrupted or not. For example, if you set Foobar's own audio buffer to a size larger than the stalls (bigger than 4 seconds is good) then you get no audio interruptions. And if stalls are shorter than what Firefox buffers for Youtube playback then you get no interruption. This is because with larger buffers the audio data has already been processed before the stall happens and it seems that the program parts that just shovel the data to the audio driver do not get interrupted during a stall.

Video:

Video playback and graphic output always get interrupted, which in turn results in GPU load and Video Engine load dropping considerably, including the GPU frequency and temperature dropping. Since timers keep rolling the video/graphic output will jump forward to match the new time-frame (a 5 second stall means that the video jumps 5 seconds forward). For Youtube videos in Firefox this is a true jump, for videos in MediaPlayerClassic this is a fast forward that shortly increases the frame-rate (while maintaining the refresh-rate, because disabling VSync doesn't seem to work properly). Both Firefox Youtube and Furmark also see their average CPU load drop because of the stalls that interrupt their processing, even though they do maintain their time-lines in form of a straight jump.

Interestingly HWInfo's graph display works similarly to how Firefox Youtube playback and Furmark works. The graph will do a full jump to the new time-frame instantly after a stall instead of drawing the in-between measurements. If you mouse-over the graph you can see several seconds being absent corresponding to the stall time.