Ableton Live 11 Support / Notes-Docs #4
Comments
|
my current options.txt
|
|
One bit needed to avoid xruns (in Jackd) with Ableton Live is to use a script like this: https://github.com/nine7nine/Wine-NSPA/blob/main/examples/system/cgprio
some of this really matters as Wine-NSPA supports niceness && Linux-NSPA supports latency.nice (in cgroups)... Strangely, linuxaudio related docs don't cover using cgroups and other handy linux technologies... I try my best to utilize these things. a few bit in here are system-specific, but can easily be adapted for other setups NOTE: I probably need to convert this type of script into a systemd service file (that also handles suspend/wake up) |
|
blank/black popup menu bug is fixed now, as of commit: a987f3f |
nine7nine
changed the title
|
Interesting note about -DontCombineAPCs
I'm not sure if this means that use of this feature is CPU dependent (and may be disabled on my i7... OR if this means that my AMD 3500U cpu just can't use this feature correctly (due to a bug, the cpu, something in wine. idk). I'll need to test Ableton Live on my Surface 7 more (with and without disabling the APC Combination mode) to make any kind of sense of it. -- Regardless, I will be using my Surface 7 now for Live 11 anyway -> the Core i7-1065G7 destroys the AMD 3500U and the MOBO on the Surface is much better designed than my Lenovo Flex 14. |
|
Another important set of details... aside from installing msvc runtimes, gdiplus needs to be installed and also a number of dll overrides: the above is a registry key that I exported from my lenovo laptop and imported onto my Surface 7 Laptop... After running winetricks, plus manually installed the x64 mscv runtimes && importing the above .reg file -- Ableton Live doesn't crash anymore on my Surface (which is a clean wine prefix / install). special note: "msvcp140_atomic_wait"="native,builtin" the above seems to be needed to avoid some VST3 crashing in Ableton Live, when closing the window (Massive X for example) |
|
odd...
after some digging, I noticed it launches fine form the command line. Easy fix: just create a new .desktop file
|
|
Great documentation, thank you. Perhaps there is more to learn from the Push 3 standalone which runs on Linux. Have you considered WINE compatibility with Ableton Push? I tried using a Push 2 with Ableton via Wine but Push2DisplayProcess.exe would fail. I now have a Push 3 which I have not tried with WINE, but it seems to use a different executable. |
|
Well, at the moment - Wine-8.x is kind of broken, in terms of getting good performance + due to limited time, atm... I'm not actively working on Ableton Live support... that'll likely change in the future, but for now I'm a bit busy (with work / life). Kind of waiting for Wine Upstream to iron out some regressions... I know nothing about Ableton Push (other than what it is / does)... but if it requires some windows driver to function - that DOA in Wine. Highly unlikely to work properly... IIRC, some of the push devices are supported by Linux though. (eg: with Ardour) |
|
Latest Wine-NSPA-devel (8.14+) are starting to work reasonably well... all of the nasty bugs that i was facing in 8.x builds have largely disappeared. I've been playing around with Ableton Live - no crashes or anything, still slightly higher CPU usage than Wine-7.5.x builds, but overall much better than a couple of months ago... So i can work on getting a stable 8.x release, along with improving Ableton Live use. |
|
Nice to see that 8x finally starts to work! I will try to build 8x soon, will report back if something is bogus. Going with a fresh arch install for now, but for maximum compatibility with my setup I will also try to get it into Debian/Ubuntu. I struggled with converting the arch custom kernel package to a debian package, so I probably will have to manually add the patches to my preferred kernel, if possible... |
|
Ya, it is nice to see that 8x builds are starting to work. Most of the issues were upstream problems, all of the PE conversion stuff, the heap stuff and CRT changes were introducing a lot of bugs (crashes, instability), but it seems that that has all been worked through now... eg: Kushview Element used to not even start/crash on Wine-8.x for a while, but now it works fine... I'd get other issues with apps freezing or 2x CPU usage with some VSTs -- but again, that all seems to not be a problem anymore... Unfortunately, this kind of thing just happens sometimes with Wine. ~ I've been using Wine since pre-1.0, and I've had custom builds of wine for almost as long. ~ the goal is always the same, but sometimes the patchwork changes (eg: old wine i used to use an entirely diffferent set of patchwork for synchronization primitves. pre-esync or fsync... RT patch used to be the one in Wine-Staging, etc)... Wine is a moving target. sometimes things work well, sometimes not... sometimes new ways of doing things are needed. Sorry, that i can't resolve the debian package issues for you -- I strictly use Arch, unfortunately... but assuming you use the same version kernel that my patches apply over (and don't use other patchwork that cause conflicts and/or can resolve conflicts) -- it should be that hard to make a custom kernel package for debian/ubuntu. |
|
Yeah thanks 4 insights... package issues: I will try makedeb -> someone built this on top of the makepkg code, to generate debian packages from PKBUILD files |
|
bah, i wrote a detailed reply, but it seems to have disappeared.
One day I likely will swtich to Pipewire, but I'm not really in a rush. It does offer some advantages over my Pulse/JACK setup, but also some regressions (and those are regressions that directly affect my use with Wine-NSPA / and proaudio on linux, in general -- so it's not the best time for me to try and switch over).
|
|
I like details ;-)
me neither, I am also waiting for IRQ based scheduling.
Do you mean the "pipewire-implementation" in Wine must be capable of doing the the same as WineAsio or must it work well with WineAsio? because there are some bug reports about the latter which I can find...
good to know that you already have evaluated these...
I will probably stick with a Arch setup anyways for now - so I can also follow your development tighter.. There is also distrobox to chime in some other distro's stuff if needed... So I guess standard procedures will needed to be done, all realtime stuff (á la realtimeconfigquickscan) define IRQ Priorities, disable unneeded stuff, run latencymon in windows / osjitter / hiccups / numbers on the machine to find hardware which gets in the way.... Probably also coping with tuning guides, turn mitigations off, rtla-tool ...CPU pinning ulatencyd, linux-music-utils, numactl...bcache, zram/zcache,, run audiogridder linux server locally to pin vst's to specific CPU cores... just throwing in some things here I encountered.. |
that aside, I'm just selective about what i run in my userspace, as well. avoiding stuff that wants to periodically run in the background, or that may introduce unwanted effects... |
|
there is also someone trying to patch wine's pulseaudio-driver for getting low audio latency, maybe from interest |
|
the osu audio patches are outdated and unnecessary, given it's jack, WineASIO, etc that are being used here / with proaudio stuff... totally aware of the osu audio hacks. I have patchwork for hacking on both the alsa and PA wine drivers ~ just haven't rebased them, since wine-devs recently reworked / moved around some of that driver code. |
|
I don't know if this is of any help, but in regards to Pipewire in Ableton Live, there's this: https://copr.fedorainfracloud.org/coprs/patrickl/pipewire-wineasio/ I'm currently trying to get this working, in order to get low latency on Ableton Live, but I had to downgrade wine from 8.18 to 8.4 due to a seemingly known bug that fails to open any input/output, whereas it works okay on 8.4, but the WineASIO script cannot be built on older wine-staging. Also, CPU temperatures are insanely high on vanilla Wine, even on idle. I really want to follow this Ableton Live 11 guide, but I'm really new to Linux audio, so I don't understand most things here. Any pointers on how to achieve low-latency audio and decent CPU temps would be greatly appreciated. |
|
Unfortunately, I don't use Fedora, but from the look of it: that WineAsio package simply links against pipewire's jack lib... ATM, I also don't use Pipewire for anything Jack-related... I have recently replaced PulseAudio with Pipewire, but Pipewire is running on top of Jack (via pipewire-jack-client). ~ which means I am using Jack in the end (not pipewire's jack implementation)... I will probably test out Pipewire as a jack replacement when Pipewire-1.0+ is available in Archlinux repos. Until then, i won't touch it. It's a bit unfortunate that you are somewhat of a newbie: as I wouldn't say setting up a linux machine for proaudio / really low-latency and messing around with custom wine-builds + running tricky software like Ableton Live is very newbie friendly, and I'd still say it's a bit experimental - although, I do run Ableton Live fine on my machine, atm. The only real advice I can give is making sure your system is actually setup nicely for prouadio, before trying anything like this. That means following whatever Wiki for your distribution that covers this stuff. For running something like Ableton Live or very new VSTs - you also need a new / powerful PC. it's not going to work well with older hardware... and honestly, I would suggest not even dealing with Live 11 - if you have a better option: such as running a native DAW + yabridge (if you need windows-specific VSTs). there is still the odd pain-point with running Ableton Live in Wine, and as you can see from above ~ it's not-trivial to do in the first place (custom builds of wine, needing XYZ ms runtimes + dll overrides, messing with ableton's hidden options -- on top of configuring your machine correctly, in the first place). in any case; rolling back my builds to Wine-8.4 isn't happening. Wine-8.4 was busted for my use-case, things weren't really ironed out until 8.10+ ~ so i definitely will NOT be going back or rebasing patches for a version of Wine that had stability issues for me. |
|
Thanks for responding! I mean, I'm experienced enough to understand technical terms and following guidelines, but obviously not enough to create and optimize a custom wine build. I built a fairly strong computer last month and Ableton Live 11 and VSTs run fairly well, with the exception of slow boot times, M4L glitches and the I/O bug on Wine-8.18. While I can deal with these, the issue of latency and high CPU temperatures worry me. I did try the Bitwig + yabridge combo and it's perfectly serviceable, but I've been using Ableton Live since 2015 and I'm really deep into its workflow, so it would have been awesome if I could use it on Linux as well. Also to clarify, I also want to use the latest Wine version just like everybody else, if it wasn't for that I/O bug in Ableton Live. |
I typically have Ableton Live 11 set between 5.33ms and 10.7ms on my system - and that works fine (even with my internal soundcard, to an extent).
https://github.com/Frogging-Family/wine-tkg-git/tree/master/wine-tkg-git it does mention building on Fedora. That all said: if you are really tied to Ableton Live - why not just use it on Windows? you'd avoid a lot of headaches. |
|
Thank you for the detailed answer, I really appreciate it. Unfortunately, as you would imagine, Wine in Fedora isn't all that well documented, as opposed to the Archwiki for instance and I wouldn't trust myself with tasks I don't fully understand, so I think I'll use Bitwig + yabridge until any further developments with Ableton Live, Wine etc and hopefully, I'll also become more experienced in programming to help out someday.
I was a macOS user since 2006 and last year, I fell in love with Linux and GNOME in specific, so I'm pretty dead set on being on Linux for the foreseeable future. |
|
No problem. I do think Bitwig + Yabridge is probably the better option. It's just less hassles / less problems. For me, I started using Ableton Live in Wine to help analyse and improve performance in Wine. - Heavily multi-threaded apps are good for that.... it's been helpful, and i do think there is still a lot that can be improved -- but most of that will continue to come from non-vanilla wine patchwork (which is why i patch + build myself). It may not be that hard to build Wine in fedora. You really would just need all of Wine's dependencies and related development packages... after that, building wine-nspa would be pretty simple (modifying one config file, executing the build script and waiting)... unfortunately, i haven't used Fedora since 2008 or something - so i'm just not up on the details, even with how things are packaged in the repos. |
|
Looks like there is some move with the NT Sync Part: https://www.phoronix.com/news/Windows-NT-Sync-RFC-Linux
is it possible that you share (some) of that into a github gist? I am trying to replicate your setup as thoroughly as possible.. |
|
@revast - yeah, the NT sync / winesync code is now beginning it's initial review. ~ I belong to wine-devel, LKML, etc mailing lists - so I did see this in my inbox / I'm following it. IMHO, this will be a lengthy process - I don't expect this kernel driver to be upstreamed anytime soon (nor into Wine). It'll take time, there will be a lot of feedback + revisions to the kernel code && Wine before it ever is accepted. I've played around with NT Sync (not in a couple of months though). It caused some stalls/freezes wiht Kontakt and some other VSTs I use ~ you'll also note the Phoronix article doesn't show benchmarks of NT Sync vs. Futex2, which may paint a different story vs. upstream wine. I'll likely give NT sync another spin, after I rebase on Wine-9.0+ (which I will do soon, likely within a month or something). ~ I'll see where it's at then, and provide builds with it (but will likely disable it by default, preferring Fsync/Futex2). |
|
Playing around with Ableton Live 12, along with my LibRTPI patchwork -- it's become pretty obvious where/what causes Ableton's one TC thread && Wineserver's one shmem thread to consume so much CPU -- it has to do with epoll_wait + FUTEX_WAKE/FUTEX_WAIT in Winserver. (In Wine-NSPA-pi build it's easy to spot: those are the only 2 non _PRIVATE / _PI futexes left, after mutex conversions). One idea I have is building a 'Monitor' synchronization mechanism - which can be built using pthread mutexes and condition variables, this could eliminate WAKE/WAIT in the server requests and potentially fix the high CPU usage of the threads. They would no longer be busy-waiting... I have no control over Ableton, but it would get rid of the spinning in wineserver, either way. It's going to take a bit of thought, research and refactoring. but it's plausible. Furthermore; it would be compatible with LibRTPI, as I can just convert the mutexes/locks- reaping the PI benefits, as well... AFAICT: Fastsync/NTsync will do nothing to fix this problem. |
Hello again, it's been a while. I wanted to ask if you also encountered that "Starting Max..." boot hang on Ableton Live 12. It seems a lot of people have had the same issue which is "solvable" by renaming the Max folder into something else, but then you won't be able to use M4L at all. Thank you for your research! |
|
ya, i saw that. thanks! Personally though: I won't consider seriously using Ableton Live in Wine until I resolve the above issue (the busy-waiting high-CPU problem in Wineserver)... Frankly, I just don't think it's worth using until then. At least on my box: it's burning a lot of cpu cycles / mucho overhead. (and obviously without using the multi-threaded wineserver: i wouldn't try using Ableton at all. IMHO, it's a complete waste of time -- because it's easy to stall wine/Ableton without it - to many server requests to a single thread). I am working on a patch though; I mostly have the Monitor thingy worked out, but currently it's getting stuck. It's not so trivial to implement. However; if/when i kill the busy-waiting: Ableton Live will become more viable (basically no overhead)... That said; I expect this is going to take a few more failed attempts / bit of frustration along the way, before I get a working implementation. |
|
No no, I've been on Bitwig for the past year and it's perfectly serviceable! It's just that, you know... the grass always being greener on the other side and all that jazz hahaha - For what it's worth though, Ableton Live 11 Suite is running absolutely spectacular via Patrick's wine-tkg corp on Fedora. Something about Wine v8.18 that solved many relevant issues and made Live 11 run almost at native level back when it was released. But regardless, working full-time on a DAW via Wine started to feel wrong, so I eventually switched to Bitwig. |
|
Yeah, upstream development during Wine-8.x fixed most of the issues with Ableton Live (black menus and crap like that). That said; Wine-TKG is actually missing some Fsync related patchwork (in non-Proton builds). I have plugins (like NI Kontakt, certain U-He plugins) that run substantially worse without them. Patrick's build is affected by that. Likewise, his builds are running a single-threaded Wineserver; -- and Ableton Live still will have high CPU on one of it's threads. So usable? maybe... But still very problematic / won't scale well. Not if running a ton of tracks with heavy plugins DSP + low latency. There's really no solution to that in any build of Wine, ATM. In mine, if I can replace the spinning -- that'll probably fix it. But it's proving very difficult to do. There's really only a couple of options; building a Monitor synchronization mechanism, using semaphores or maybe spinlocks... Each has there own specific-issues/difficulties to get working properly. Yeah, Bitwig is very good, and probably the best option for a Native Ableton Live-like DAW on Linux. For my own use-case: While I have been experimenting with Ableton (and it's been helpful in that way; testing, finding issues), I primarily use my VSTs in Kushview Element (with carla-single + yabridge). Basically, running them in containers... More live-play with some midi/ recording (controlled from DAW, routed in). I haven't had any issues with my setup in a long-time... It's really just ableton that exposes the spinning/scalability problem in an obvious way. |
In playing around with Live 11 with Wine-NSPA-7.5, I've been able to identify some issues (and fixed some).
That covers the basics and beyond. Ableton Live 11 is actually usable now.
What does "usable" mean?
TODOs:
Live 11's two main threads use an excessive amount of CPU. As it turns out, Ableton Live has a configuration file that can be modified and has a number of hidden settings. ref: https://github.com/ibekso/medium/blob/main/article_ressources/options_txt/lists/options_available_live_11.txt ... One stuck out to me as being a possible cause of the high CPU usage, so I did some more digging, we have a option relating to APCs;
ref: https://help.ableton.com/hc/en-us/articles/6003224107292-Options-txt-file
Turning on this option eliminates one of the high CPU threads (that causes 30-40% CPU usage on all CPUs). ~ That said, I have observed higher CPU usage one a given specific thread (at a time), but all of the rest consume much less CPU. Overall CPU usage on idle is waaaay down...!! This should improve performance, while being far more energy efficient.
The text was updated successfully, but these errors were encountered: