WINE is not an emulator, thus comes the acronym “W.I.N.E.”, and is one of my favourite things. Why? Because I’m one of those cretins who had a mildly bad time with Windows, and then decided to sign away my rights and watch way too many The Linux Experiment videos for my own good – which is a long winded way of saying I began to use Linux. Honestly, the switch to Linux wasn’t all too bad, and only two pieces of software were causing me trouble (i.e., had no equivalent that I initially planned on using).
WINE, via anything but emulation, allows Windows executables to run natively (i think it counts as natively?) on Linux. So, problem solved… right? Take any applications you used to run on Windows, and just shove ‘em through the magic that is WINE?
When I made the move to Linux, I still used GameMaker (at the time called GameMaker: Studio 2) for creating games. It was the first game engine I properly put some time in, primarily through the likes of Heartbeast and Shaun Spalding. But ever since the former began using it, a, now familiar, name began to pop up: Godot. I plan to talk about Godot in much more detail, but let’s just say that it’s f*cking fantastic – definitely a change from what I’m used to, and certainly something that I need to properly get stuck in to before I make something large scale, but brilliant nonetheless.
Godot became GameMaker’s replacement. Sure, I tried running it through WINE, but alas to no avail. Then I tried an integrated virtual machine, but that’s really clunky and definitely something that I wouldn’t want to consistently use. Because of this – and the fact that I needed to learn Godot for my A-Level programming project, because of reasons that I implore you to read about – I stuck with using Godot, and I’m really quite glad with my decision. Plus, it’s always good to get out of your comfort zone, and learn something new. There’s no doubt that Godot has improved my ability to program simply due to it being different, requiring me to think differently about how to approach problems.
Okay… so why not use a DAW made specifically for Linux? I mean, I did the same for everything else (e.g., began using GIMP instead of paint.net). Well, I tried REAPER… but VST support requires WINE anyway, and if I was to run the Windows version of REAPER through WINE anyway, I may as well stick with what I’m used to. That’s not to say I will forever, to be fair. REAPER is certainly an extremely capable DAW, and probably much better than what I currently use, particularly for WINE compatibility. And you’ll start to understand why shortly.
Mixcraft is the name of the game. Specifically, Mixcraft 9: Recording Studio. Why 9? Well, it used to be the latest until version 10, very recently, came out. But I’m fine with 9, and got it all working on Linux… sort of.
WINE can be complicated to set up, particularly for a novice Linux user, such as myself. Many programs exist (particularly for gaming) to help with this, such as Lutris, or even Steam through Proton, a custom version of WINE optimised for gaming. To help with my DAW troubles, however, I decided to use Bottles. Bottles is a program that manages WINE prefixes (i.e., separate configurations of WINE, all running in different locations), and ensures a sandboxed environment, which can be useful a lot of the time. It can also be a bloody pain, but doesn’t end up interrupting my workflow, really.
So, after some initial set up, I managed to get Mixcraft working… in the Flatpak version of Bottles. Whilst this was actually a good thing, as Bottles encourages running through a Flatpak to ensure full sandboxing, it still baffles me that I could only get Mixcraft to work in this particular version, even if the runner is the same. What changes you ask? Well, for whatever reason, the non-Flatpak version of Bottles cannot use my audio device, thus I get absolutely no audio whatsoever – which is kind of important if making music, I think.
Either way, when all is said and done, Mixcraft works quite well, and I’ve got VST support through WINE. Sure, there’s been some hiccups, but overall nothing that 30 minutes on Google couldn’t fix, such as the dreaded Native Instruments VST install. Although, ASIO is a pain in the backside that I just can’t deal with right now – if you need low latency for recording from something like a MIDI controller, be my guest and get WineASIO working, but for me, it’s more trouble than it’s worth (mainly because JACK is more trouble than it’s worth)
So, why write all this down in a post on my website? Well, after needing to reinstall Linux for some reason I’m yet to fully understand (something completely locked the file system, and made it impossible to boot, and also took up all the space on the drive?), and setting up the Bottle just fine, I began to run into a strange problem: the mouse sporadically froze. Seemingly at random intervals, but extremely often, my mouse would stop working. And even weirder, the light at the bottom of the mouse flashed whilst it was frozen, indicating it was disconnected. Surely enough, closing Mixcraft resolved this completely, and I had never encountered any other problems with the mouse on Linux. So, what the hell is up with that? Well, I’m not entirely sure what caused the issue, but I did manage to resolve it. I ended up changing three settings in Bottles to resolve this issue:
- Change “Synchronisation” under “Performance” to “Esync”
- Turn on “LatencyFleX” under “Components” (to the latest version available)
- Change the “Runner” under “Components” to “GE Wine”
Esync is likely to be the only thing that ended up mattering here, but I also think the other two generally improved performance in the Bottle. For those who don’t know, GE WINE is a custom build of WINE based off of Steam’s “Proton”, but for use outside of Steam with non-steam games and applications. It’s spectacular to have such a thriving community on Linux creating what are almost necessities for free, and keeping them open source. So, massive shout-out to Glorious Eggroll for GE WINE, and all the people who make WINE possible in the first place.
Even with that, WINE is not perfect, and I still get weird, and frankly annoying crashes in Mixcraft, from time to time. This is not an insult or criticism to the people who make WINE possible, however, but rather a warning to those who could – and should – use WINE. So, for the one person that sees this, please for the love of all things holy, do not press play and save in Mixcraft at the same time. You will corrupt your project file and have to use a backup, which is a minor inconvenience if you didn’t save recently. Especially if you just cut up a bunch of takes playing the Casino Night Zone theme from Sonic 2.
Okay so, turns out this problem was definitely not exclusive to Mixcraft. Mouse stuttering issues in WINE seem to be commonplace, with certain bugs plaguing the Bugzilla forums. However, I believe I’ve come across two additional things that, at least partially, rectify this issue.
You see, the issue came back whilst playing Subnautica through Proton (and ProtonGE). The first thing I did after a lot (and I mean a lot) of Googling was enabling C-States in my BIOS (or changing it from “automatic” to “enabled”). This seemed to help the stuttering, at least partially, but it didn’t completely fix it. My previous solution of E-Sync or F-Sync didn’t seem to change anything.
Randomly, I was trying to get my microphone to be picked up, but nothing would detect it. A quick gander into the audio settings and I noticed my audio interface (Scarlet 2i2) was not set to “Direct Scarlet 2i2 USB”, unlike how it previously was before I had to reinstall, due to an unrelated issue. So, I changed it from whatever it was before – maybe Pro Audio but I’m not certain – and two things changed: the sound quality was improved, particularly soundstage, unless that’s just placebo. But more importantly, the mouse stuttering seemed to have completely vanished.
Back when Subnautica was in early access, I had trouble running it on Windows due to audio issues, and the only solution was using Microsoft’s default drivers, rather than the Realtek ones. So, the mouse stuttering issue in WINE may, in fact, be related to applications that heavily rely on certain audio features, e.g., DAWs. Obviously, there’s also the fact that it could simply be coincidence, but it’s certainly something to note. Anyway, that’s all for this update. TL;DR: enable C-States and check audio settings in Linux, it might just fix it completely.