1 Topic by theSurge (edited by theSurge 2022-08-08 05:32:50)

  • Registered: 2013-03-14
  • Posts: 11

Topic: The (Mostly Working), Long-Awaited Guide for RME + Linux

Sick of Windows garbage?  Maybe you also didn't take a liking to Windows 11.  It really sucks; no desktop customization whatsoever.  Meanwhile, over in KDE/GNOME land (I should specify Wayland), we have all the customization we could ever want.  Rainmeter?  Not really the same as having a native Desktop manager.  And does it irk anyone else that Microsoft watches everything we do via its invasive telemetry?

I took the plunge a few weeks ago, and I have an even more reliable system now.  Even though I get xruns still, when I do, I don't get a BSOD; instead, the Linux kernel keeps on ticking, brushing it all off.  Windows VSTs?  Sure.  Kontakt 6?  Sure.  Latency?  Well... it fluctuates...

Before I get in to the real meat of this tutorial, I'll stipulate that running Windows probably still works the best and has the best performance over Linux; getting all the plugins to work takes time, and if you work in pro audio as a career and you have limited knowledge of working with Terminal, then probably better to stay away from this.  This is still an experiment, but it works.  So try at your own risk.

1. Install Manjaro.  I choose to go with Manjaro after tinkering for a few months with KDE Neon as my main driver and landed on it because it supports changing kernels easily.  If you do have an existing Linux Mint install or other debian-based distro, then check out the licorix kernels; with pipewire, I think they'd work very well, though I have only tested so far with jack2/jackd.
2. Follow this guide here: https://github.com/ElizabethHarmon/ManjaroProAudio.  Elect to follow the pipewire instructions/setup.  I had issues with far more xruns using jack/carla, but there's also an equivalent audio guide for Ubuntu users here: https://github.com/ElizabethHarmon/UbuntuProAudio.  It's probably because the buffer size varies from app to app, so every app doesn't have to match the global buffer size.  Speaking of buffer sizes, I just set the global buffer size to 128 and the sample rate to 48000.
3. Install and configure wine-staging as per the guide.  Map a shared drive in the wine config to wherever you store your VST plugins.

winecfg

https://i.ibb.co/xqrWTfh/image.png
4. Import your Windows plugins:

yabridgectl add "/run/media/seang/Installed Games and Applications/Backups/VST2/"

(you can find the full path in Dolphin and copy-paste that path in, as in the examples above)
5. Generate the linux .so files for the imported Windows VST plugins:

yabridgectl sync

6. Install ffado-mixer and monitoring friends.  You can use the built-in package manager to install ffado-mixer and qpwgraph at the very least.
7. Configure ffado-mixer to always launch when the PC launches.  Without this, you won't be able to adjust the mic gains and perform routing like you would normally do in TotalMix.  In fact, ffado-mixer is very close to a full replacement of TotalMix!
https://i.ibb.co/Y7zKq9v/image.png
https://i.ibb.co/ydCZ2Ny/image.png
For example, you can perform full routing and send from inputs to outputs via the routing matrix:
https://i.ibb.co/BNmHLd0/image.png
8. Open up your DAW of choice and profit.  Make sure to use the ALSA drivers for output device (for example in REAPER).  Play around with the settings here.  I've actually completely frozen Manjaro from here by using basic settings here: 3 frames at 128 buffer size and 48000.  Play around with the RT priority, but probably 90 at least.

Known Bugs
1. Mic gains do not persist after reboot and reset to 0db, so we need to manually reset them on boot (hence step 7).
2. Audio delay when watching videos.  I think this has to do with the Clock Source not set to "Internal" as it would be in Windows.  Looking at that now, but if you experience delay in this way, try using mpv to watch your videos (or vlc), and adjust audio delay accordingly
3. xruns when playing video games -- and in real-time priority tasks.  With proton + wine working quite well, note that you'll get sync issues until I can figure out how to use the RME interface with "Internal" clock source.
4. Audio not at 100% quality; I do notice a slight "tinniness" to the audio on Linux.  Perhaps not the full spectral range or suppressed sample rate differences with aliasing or something to that effect.  I had much worse before when using PulseAudio and ffado, so pipewire really does sound much better than ALSA + Pulseaudio.

Pleasant Surprises
1. Volume rocker(s) on keyboards work as expected
2. Mute button works as expected
3. MIDI and audio inputs work out of the box without requiring any configuration; simply select your audio interface as the input device, and you should be good to go
4. Surround/quad/5.1 works, but the configuration of outputs slightly differs from Windows.  Thankfully, you can visually configure this in qpwgraph.

Further Troubleshooting
1. Force your buffer size to 128:

pw-metadata -n settings 0 clock.force-quantum 128

2. Monitor your app for xruns (errors):

pw-top

3. Visualize the patchbay in qpwgraph or Helvum

2 Reply by ramses (edited by ramses 2022-08-08 05:53:59)

  • ramses
  • DAW Mastermind
  • Online
  • From: UTC+1
  • Registered: 2012-10-14
  • Posts: 13,182

Re: The (Mostly Working), Long-Awaited Guide for RME + Linux

Excellent work, many thanks, a very nice starting point for people with interest.
Manjaro is IMHO also a good pick for a rolling release.

Sorry to hear about bad audio quality and delay when watching videos.
But, if this can't be fixed, where is the advantage of Linux over Windows?

You claim Windows is garbage and instabilities on Windows, but I had no BSOD since Windows 7 (maybe around 10-15y)
and Windows is still one of the two major platforms for DAW work.
Yes, I also dislike Windows 11, but it also doesn't help if Linux is not a real alternative for professional audio work,
if audio quality is not at 100% and low latency is also a strong requirement.

BR Ramses - UFX III, 12Mic, XTC, ADI-2 Pro FS R BE, RayDAT, X10SRi-F, E5-1680v4, Win10Pro22H2, Cub14
  • Registered: 2013-03-14
  • Posts: 11

Re: The (Mostly Working), Long-Awaited Guide for RME + Linux

ramses wrote:

Excellent work, many thanks, a very nice starting point for people with interest.
Manjaro is IMHO also a good pick for a rolling release.

Sorry to hear about bad audio quality and delay when watching videos.
But, if this can't be fixed, where is the advantage of Linux over Windows?

You claim Windows is garbage and instabilities on Windows, but I had no BSOD since Windows 7 (maybe around 10-15y)
and Windows is still one of the two major platforms for DAW work.
Yes, I also dislike Windows 11, but it also doesn't help if Linux is not a real alternative for professional audio work,
if audio quality is not at 100% and low latency is also a strong requirement.

Linux has more customizability and better overall performance for non-audio tasks, as it requires less CPU/RAM to run the kernel.  For low latency, it is possible, but my performance wavers inconsistently, and I still haven't found the right settings for REAPER via ALSA.  So these problems can be fixed, and we should also remember that at this point, at the time of this writing, the RME team has not contributed with an official Linux driver, so the performance we have now is only the tip of the iceberg.

4 Reply by ramses (edited by ramses 2022-08-08 07:27:24)

  • ramses
  • DAW Mastermind
  • Online
  • From: UTC+1
  • Registered: 2012-10-14
  • Posts: 13,182

Re: The (Mostly Working), Long-Awaited Guide for RME + Linux

Don't get me wrong, I am not against Linux (I started with Unix a few decades before as pro) or your solution.

I mention this only because you are doing Windows / Windows 11 bashing and claiming Linux would be the better solution, but sorry, this is really not the case, at least not under a professional perspective.

My personal experience, in short: over time, I got more and more application requirements that cannot be fulfilled by Unix / Linux. Additionally, it takes too much time to get all working.
Definitively not helpful is, that over 200 Linux distros exist where every team has another idea about system setup and operation and which combination of open-source packages they use.
Another big issue is, that documentation on the internet (Wikis and what not) is not up-to-date, and you need to experiment. In some areas, you simply need to become a Linux nerd to get things working, or not.

As nice as Unix (not necessarily Linux) is… In the datacenter area, it can shine with the proper distribution and if people know how to operate it. For private use, it can also be pleasant, to get a box up for simply browsing the internet.
But if you want more than such trivial things, then it can become much harder to operate and get a satisfactory solution compared to Windows and Apple. It's this high level of customization which can cause issues of its own, and the many differences between distributions make it additionally harder to operate and support (esp. for companies offering products).

For audio / video / DAW work, I think that you are still better off to use Windows or Apple. Most people do not have time for such customization under Linux. And I have to admit, also for me (even as Unix pro), it's much easier and more pleasant to use a Windows environment where most things are much easier to implement.

If you want to compete with Windows / Apple and want to become a real alternative, then you need to be better, and this you can only achieve with a certain level of standardization. In my opinion, it was a fault of Linus that he only concentrated on the kernel and didn't deliver a complete OS, this bazaar style of distributions allows for too many deviations and issues of its own.

For audio professionals who run a business using commercial software, you need a stable platform which is fully supported in terms of hardware and applications. This is also my preference, even if it's “only” a hobby, as I want to avoid wasting too much time on unnecessary things.

BR Ramses - UFX III, 12Mic, XTC, ADI-2 Pro FS R BE, RayDAT, X10SRi-F, E5-1680v4, Win10Pro22H2, Cub14
  • Registered: 2020-04-09
  • Posts: 108

Re: The (Mostly Working), Long-Awaited Guide for RME + Linux

I have tested RME 802 and UFX+ devices on Linux and Windows 10 systems. On the same machine. There have been no problems with the sound quality. The only difference is the absence of totalmix fx. Things work more stably on Linux.

I don't understand this Linux fault finding. The problem is open source, which everyone seems to hate.

  • Muffin
  • S/Mux specialist
  • Offline
  • Registered: 2021-12-26
  • Posts: 193

Re: The (Mostly Working), Long-Awaited Guide for RME + Linux

sjzstudio wrote:

I have tested RME 802 and UFX+ devices on Linux and Windows 10 systems. On the same machine. There have been no problems with the sound quality. The only difference is the absence of totalmix fx. Things work more stably on Linux.

I don't understand this Linux fault finding. The problem is open source, which everyone seems to hate.

More "stably on Linux"? You obviously don't know what you're talking about starting with what is "Linux".

7 Reply by sjzstudio (edited by sjzstudio 2022-08-08 18:27:40)

  • Registered: 2020-04-09
  • Posts: 108

Re: The (Mostly Working), Long-Awaited Guide for RME + Linux

Muffin wrote:

More "stably on Linux"? You obviously don't know what you're talking about starting with what is "Linux".

Can you clarify a bit. Maybe there is a language barrier here.

Maybe it's because I'm using Mixbus 32C and it's apparently originally coded for the Linux environment. Because is an Ardour derivative. But as I said, on the same machine, things work more smoothly when I use it on the Linux side. On the Windows side, it's not so good.

Of course, it could be that I don't know anything about anything and I'm wasting everyone's time. So it's probably a good idea to leave the writing here to better people.

8 Reply by Muffin (edited by Muffin 2022-08-08 19:15:49)

  • Muffin
  • S/Mux specialist
  • Offline
  • Registered: 2021-12-26
  • Posts: 193

Re: The (Mostly Working), Long-Awaited Guide for RME + Linux

sjzstudio wrote:
Muffin wrote:

More "stably on Linux"? You obviously don't know what you're talking about starting with what is "Linux".

Can you clarify a bit. Maybe there is a language barrier here.

Maybe it's because I'm using Mixbus 32C and it's apparently originally coded for the Linux environment. Because is an Ardour derivative. But as I said, on the same machine, things work more smoothly when I use it on the Linux side. On the Windows side, it's not so good.

Of course, it could be that I don't know anything about anything and I'm wasting everyone's time. So it's probably a good idea to leave the writing here to better people.

This is not about being hostile to open source desktop OS but to realize the needed support and stability to be able to do the work that is needed to be done to make a living. For most people an OS is just a tool using the applications they need to get that done, and for desktop a Linux distro is in many (most?) still a poor match.

That said, I started programming as a teenager around 40 years ago and have seen many computers, OS, programming languages since then. I even used SUSE (a Linux distro) for desktop for several years, followed by OpenBSD and FreeBSD. A decade ago I switched to Windows for needed applications for desktop usage but still used OpenBSD as well as Linux for server usage, mostly at work.

The various *BSD flavours, like OpenBSD and FreeBSD, are a much better experience than Linux for desktop where it not for needed HW drivers (like graphics cards). The documentation, especially for OpenBSD, is excellent. For Linux: Piss poor, to put it mildly. The WWW is filled with awful Linux HOWTO's.

I certainly understand why RME does not officially support Linux with their own drivers, including TotalMix FX and DigiCheck: A support nightmare.

They have in the past helped developers with info/code to make drivers. Perhaps RME can publish more info as to make it easier for others to make their own drivers and duplicate TotalMix FX. Perhaps make improvements to their Class Compliance to make their devices work more comprehensively/better on OS like Linux. My guess is that you'll have much more success with that than requesting RME Linux drivers.

  • Registered: 2020-04-09
  • Posts: 108

Re: The (Mostly Working), Long-Awaited Guide for RME + Linux

My last post to this forum:
https://linuxmusicians.com/viewtopic.ph … mp;t=24781

I gave up hope. Even Linux people don't understand that the problem is real. I think I'll move on to another art form. Good times everyone with your art and music. Peace.

10 Reply by Muffin (edited by Muffin 2022-08-08 22:09:51)

  • Muffin
  • S/Mux specialist
  • Offline
  • Registered: 2021-12-26
  • Posts: 193

Re: The (Mostly Working), Long-Awaited Guide for RME + Linux

sjzstudio wrote:

My last post to this forum:
https://linuxmusicians.com/viewtopic.ph … mp;t=24781

I gave up hope. Even Linux people don't understand that the problem is real. I think I'll move on to another art form. Good times everyone with your art and music. Peace.

Why would you move on to another art form because others don't agree with your choice of Linux distro? To me this seems to be that the tools themselves are most important to you and not the art (i.e. what you create). I'm not an artist/musician but do find this perplexing as the tools in this case appears to be digital only.

I understand perfectly well what you are trying to say with respect to Linux support for your needs/wants, and as I wrote above above I've been around for a number decades in programming (including for open source). What I think you don't understand (from reading your post on LinuxMusicians that you linked to) is that a project, like "AV Linux", is a voluntary endeavour by people doing it on their free time with no pay. In this case, a single developer, who obviously cared about this for a very long time and spent very many hours on it. Then you want other developers to contribute to this project, also on their free time, for your needs, never mind what they want to spend their own unpaid time on. It's no surprise that your pitch fell flat.

  • Registered: 2020-04-09
  • Posts: 108

Re: The (Mostly Working), Long-Awaited Guide for RME + Linux

You are right and I am wrong and I misunderstood things. I'll try to be wiser in the future. I apologize.
Does this FFADO mixer work for USB devices like 802 and UFX+?
That could solve a lot of things aAnd I could use these devices more on the Linux side. If not, we'll just have to wait for the next invention.

  • Registered: 2013-03-14
  • Posts: 11

Re: The (Mostly Working), Long-Awaited Guide for RME + Linux

I don't have any USB RME devices and currently only have my Fireface400 plugged in via firewire.

  • Registered: 2013-03-14
  • Posts: 11

Re: The (Mostly Working), Long-Awaited Guide for RME + Linux

Update on latency: I was able to achieve low latency in REAPER via the ALSA driver, but discovered that any xrun/error will cause the Linux kernel to panic and freeze (with that dastardly sustained sawtooth continuing until I reset my machine).

Using "Jack" just causes the xruns to be ignored, so maybe I'll try posting about this on the REAPER forums to see if anyone else has this same issue.

As for performance in other places, I discovered mpv player has a "low latency" mode, and pipewire has the "Pro Audio" mode, which might help to achieve "bit perfect" playback.  I still continue my experimentation, and continue to get more xruns than on a Windows machine, but still very usable, even at 128 requested sample rate.

  • Registered: 2024-09-02
  • Posts: 1

Re: The (Mostly Working), Long-Awaited Guide for RME + Linux

Forgive updating a rather old forum post but I was hoping someone might have mirrored the original documentation linked in the initial post? It seems the github links are no longer active.

Trying to get an RME HDSPe working on Linux. Works great on Windows 10 (as an aside, wow is TotalMix good! First time I've used it and it blows everything else I've used to this point completely out of the water).

On Linux, however, I've built the driver and tools via (https://github.com/PhilippeBekaert/snd-hdspe/pulls) and can see it in ALSA. However PulseAudio doesn't seem to like it as it has >32 channels. I'm not sure how to get around that. Initially for Linux I just wanted to have desktop audio out as the line out beats the pants off my integrated sound card and that would let me route fewer wires to my studio monitor mixer from my PC. A second bonus is I could start messing with Reaper for doing mixing or analog mixdowns but that's for another day (and I suspect I might have less problems with Reaper itself than getting desktop audio working).

Welcome to thoughts/suggestions!

  • geroi
  • ADAT user
  • Offline
  • Registered: 2024-11-01
  • Posts: 29

Re: The (Mostly Working), Long-Awaited Guide for RME + Linux

On linux not just low latency is possible but realtime operation. Perhaps the best choice would be gentoo or funtoo as it has flag 'realtime' for compiling anything + -ofast and other pleasant benefits. To get realtime follow large rhel guide for tuning servers for realtime, it's appropriate for any soft, not just for servers. Second, you should get rt kernel with rt patches from kernel.org and disable all not needed for audio in config file. Under those coditions fullfilled it's possible to get realtime with old pci interfaces like delta1010lt, audigy2 (not echo, not aardvark). Realtime=latency <1ms officially. Don't install jackd as it breaks realtime as per Steven Rostedt. Then use chrt command to redistribute priorities. Oss v3 driver was better than alsa as it ran in kernel space as far as i have understood it. Someone debated that alsa and all ko-modules run in kernel space too. I have no exact info on that. But with oss4 you can set granularity to adapt driver to realtime. Unfortunately oss have had no rme support. Even better option is rtai which is hard realtime (can be found in linux-cnc) and again no support in reaper for linux of neither oss nor rtai. Rtai would work like that hw rt abstraction layer for pyramix ie parallel subkernel or hard scheduler not surbodinated to os at all, so nothing can interrupt it though it's superfulouse as even rt patches give realtime. Audigy2 supports buffer:2  periods:1which is crazy fast realtime. Most vsts will refuse to work already with buffer 8 as they simply require more time to give out the calculation result. Some plugins fail at buffer 16. It was hated and criticized for its non-support of 44100 but all this seems so triffling in comparison with its scientific-level fast operation + dsp programing feature via kx driver (not possible on linux).
Ps. Choose linvst over yabridge for realtime...