Interesting discussion on the RME forum, related to Linux drivers. Not directly related to Ardour, but Linux driver support…
Why is it so hard to accept linux? (Page 1) — Linux — RME User Forum
1 Like
A few of the contributors to that discussion seem to be confused about the amount of work that would be required to support Linux. All distros are running the same Linux kernel. Some might upgrade to a newer version before others, but ultimately if you write a device driver for one Linux distro, you write it for all of them.
There also seems to be some confusion about the difference between kernelspace and uesrspace. Userspace (really GNU) ABIs don’t care about backwards compability because they don’t care about binary support in the first place, but Linux the kernel does care about ABI compatability. Linus makes that point very clearly in the video linked in that thread (Linus Torvalds on why desktop Linux sucks - YouTube).
Whether or not it’s worth RMEs while to write drivers for Linux, I couldn’t say, but I will note that the first time I ever heard of RME was during a search for a DSP card that would run on Linux and the RME Hammerfall frequently came up. Unfortunately I don’t think the DSP part of that card is actually supported. If it was I would probably have bought it already.
Not quite true. If you get your driver in tree then usually the kernel developers are good about helping keep it updated when kernel API changes occur, but I was fighting recently with an out of tree driver that was written for an older 4.x kernel, and several timer APIs were being changed through the development of the 5.x series and kept breaking the driver. The ABI stability you refer to is only the exposed interface from the kernel to user space, the kernel explicitly does not have a stable in-kernel ABI for drivers, nor is there even a guarantee of in-kernel API stability, as demonstrated by my problem with timer API changes.
But that is primarily a problem for out-of-tree drivers, once a driver is accepted into the kernel tree, the developers are pretty good about updating any places that use a changed API, so the real solution is get the driver fully working and accepted into the kernel to reduce those kinds of problems.
Which presumably means it has to be GPL licensed. That’s fine by me, but I thought Linux tried to accommodate proprietary software.
Linux has never tried to accommodate proprietary kernel drivers. Proprietary software in user space is completely separate and unrelated to the kernel, it is long established that software which uses only published system API calls has no GPL requirements.
Whether you can distribute closed source kernel drivers is actually an open question which has never been fully settled. Some vendors try to work around that by having a GPL shim layer which accesses the kernel, as a buffer between kernel code and closed source driver code, but again that it untested in a legal sense.
Multiple times the core kernel developers have specifically stated that they do not care if kernel API changes break out-of-tree drivers because they are not responsible for out-of-tree, if someone cares about that they need to make the driver open source and get it in the tree.
In the particular case I referenced the driver actually is GPL, it could in principle be included in the kernel tree, but it has limited user base so there would be issues of who maintains, who will get it conforming to kernel code standards, and also it has a user space configuration tool required, so questions about who maintains the user space tool and keeps it in sync with any changes, etc.
The Hammerfalls are still fully supported. The problem is that most of them (except the Babyface) are PCI or even PCMCIA cards. I’ve run my old Multiface PCMCIA until three months ago on a slightly dated Lenovo Thinkpad without any problems. The DSP still is supported, if I’d get an older PCI adapter for the breakout, I’d still run it on my PC which still has a PCI slot if these cards weren’t as rare and expensive. So, if you’re lucky and can get a second hand Babyface or Multiface for reasonable money, you’re still well off.
2 Likes
Found that RME802 works with AVlinux and Mixbus 32C. Admittedly, since Totalmix FX features are not available, I don’t know what would be the best option for doing headphone mixes. With short latency and monitoring through software, running large sessions can be a pain.
There used to be an app named hsdpmix, IIRC, and a second one named
hsdploader on Debian at least, that would do anything TotalMix does. You’ll need the right firmware and I can’t guarantee it supports the 802. If the kernel does, OTOH, I don’t see why the rest shouldn’t. Have you tried connecting it with Qjackcontrol or similar? The Babyface, which was recognized by the off the mill snd_usb_audio module when in class-compliant mode works pretty well with jackd all without hsdploader or specific firmware.
Something might be happening on the Alsa side. Totalmix fx features would be awesome, but can go on forever before it comes. [PATCH 0/6] ALSA: fireface: add support for Fireface 802 and UFX
Yes. I didn’t immediately realize that “802” meant “Fireface 802”. Nor
did I have in mind that the FF802, unlike my UCX, is supported by
class-compliant(?) usb-snd-module.
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.