[Bug 50155] New: Ableton Live: multicore audio processing causes high CPU usage across multiple audio backends

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=50155

Bug ID: 50155
           Summary: Ableton Live: multicore audio processing causes high
                    CPU usage across multiple audio backends
           Product: Wine
           Version: unspecified
          Hardware: x86-64
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: -unknown
          Assignee: [e-mail]
          Reporter: [e-mail]
      Distribution: Ubuntu

When running Ableton Live, if multicore audio processing is enabled, CPU usage
will drastically increase, causing unpredictable audio crackles and overall
unstable performance.

The easiest way to test this is using Ableton Live 9; Live 10 also has the same
issue, but multicore audio processing is permanently turned on.

- Open an empty Live Set. (By default, this has 4 empty tracks, a reverb
effect, and a delay effect: a negligible amount of audio processing.)
- In Ableton's preferences, under the CPU tab, disable multicore audio
processing. Observe the built-in CPU meter in the upper-right corner; it should
sit very low (0-1% on my system).
- Enable multicore audio processing. Even with an empty Set, observe that the
CPU meter jumps to at least 10-20%. On Windows, idle CPU usage should remain
identical between single and multicore modes.
- Attempt playback of a nontrivial Set; for example, a few tracks of recorded
audio. A Set that plays back fine in single-core mode will exhibit
unpredictable audio crackling and rapid spikes in CPU usage when using
multicore mode.

I have tested this across multiple versions of Ableton (various versions of 9
and 10 both exhibit this issue), multiple audio interfaces from various
manufacturers (Behringer X32, NI Audio Kontrol 1, onboard chipset audio,
PreSonus FireStudio), and even multiple audio backends (winepulse,
wineasio->JACK). The issue seems to be most pronounced when using pulseaudio,
but it is present across all audio backends.

Most importantly, this issue can be duplicated using wineasio and a JACK server
with the dummy backend (aka not connected to any audio interface).

I am unsure where to start collecting logs for this. One guess: perhaps there
is some sort of delay or sleep occuring while a mutex is being held?

This is possibly related to #47458; however, that specifically refers to a test
case for PulseAudio, whereas this bug occurs across backends.