[Bug 50155] New: Ableton Live: multicore audio processing causes high CPU usage across multiple audio backends
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: wine-bugs(a)winehq.org Reporter: sirwinstoncat5(a)gmail.com 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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=50155 sirwinstoncat5(a)gmail.com <sirwinstoncat5(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, performance -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=50155 johnstonljordan(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |johnstonljordan(a)gmail.com --- Comment #1 from johnstonljordan(a)gmail.com --- Ableton Live 11 exhibits the same high CPU usage on Idle, as previous versions. SOme of the issues that @sirwinstoncat5 reports can actually be worked around, by using out-of-tree patchwork; such as Fsync/Futex_Waitve code from Proton, wine-RT patch (and some related hacks)... and the wineserver issues can also be worked around by using a patch that creates shmem per thread for server requests.. when all of the above is in use - Ableton Live 11 does not experience any CPU spikes and is actually usable. (in Live 11 - multi-code mode is the default). I actually have it working quite well - but the high CPU usage on idle still remains.. -- it seems like there may be some blocking calls somewhere in Wine (user32, win32u or somewhere like that) that are causing the high CPU usage. I'm currently using a wine-fork of my own, based on Wine-7.5 (but also contains a lot of Proton code, staging and other stuff). watching wine-git I am aware of some significant changes, that may fix this issue - but I can't really test them, atm... - That said, if anyone reads this and has some tips on how to debug Wine to find where/what the high CPU usage is caused by on idle: i'd be more than willing to try and debug / find the issue -- but off hand, I'm really not sure how to do this... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=50155 Ken Sharp <imwellcushtymelike(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |7.5 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=50155 --- Comment #2 from johnstonljordan(a)gmail.com --- This bug should be closed, it was fixed by a patch that Proton was carrying that was merged into upstream wine. I don't know the commit number, but the patch was called "dwmapi: Sleep in DwmFlush()". With that patch merged the high cpu usage (even on idle) with wineserver went away. There still are other performace realted issues that Fsync or WineSync help address, but this particular bug directly has to do with the dwmapi patch that was merged already. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=50155 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12(a)gmail.com --- Comment #3 from Zeb Figura <z.figura12(a)gmail.com> --- (In reply to johnstonljordan from comment #2)
This bug should be closed, it was fixed by a patch that Proton was carrying that was merged into upstream wine. I don't know the commit number, but the patch was called "dwmapi: Sleep in DwmFlush()".
With that patch merged the high cpu usage (even on idle) with wineserver went away. There still are other performace realted issues that Fsync or WineSync help address, but this particular bug directly has to do with the dwmapi patch that was merged already.
Are you sure this is the same bug? The original reporter mentions a stark difference between single-core and multi-core idle CPU usage. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla