The Curious Tale of Latency, The German Engineers and The Xilinx Spartan.
If you don't know what a Xilinx Spartan is, it's a field programmable gate array or FPGA. Using FPGAs in their audio interfaces, rather than a dedicated sound chip, was an early decision taken by RME that has contributed to what the company is today. I have an RME HDSP 9632 in this machine, and I know it uses a Xilinx Spartan because I saw that chip on the card when I installed it. You could think about an FPGA as a general purpose matrix of logic gates that are programmed to provide the desired functionality.
Strangely, given RME's mystic latency aura, using an FPGA is the slower way to do it. I notice in the linked video discussed above, our host brims over with excitement when talking about RME proprietary drivers. In our host's world, proprietary drivers are good. The more ™s, ®s and ©s littered about the place the better, right? Well, not for me. I am wary of those symbols.
Because a dedicated sound chip only does one thing, it is inherently faster at that one thing. RME's move paid off because the bottleneck was not the sound chip -- it was the drivers, or what passed for drivers in Windows land at that time. I tend to think RME's drivers are, and I quote, "legendary" amongst Windows users because RME write actual drivers while the other manufacturers try to, but don't quite pull it off.
Why did RME choose an FPGA, though? Well, Ralf Männel and Matthias Carstens, the German engineers of this story, had a problem to solve, and that problem was ... latency. Like many engineering solutions the answer was to accept the underlying problem (it was unsolvable), and find a workaround. This was back in the late 90s, before Digidesign became Avid, and Protools was still a half hardware/half software solution. Latency was just too high to monitor through the computer while having a few plugins on tracks.
The solution was to leave the computer audio at a higher latency and monitor through a digital mixer implemented on the FPGA. The mixer uses 40 bit internal precision so that all the channels can be going at full tilt at the same time, and still not overload the internal bus. 40 bits? Are you crazy? Nope, it needed 40 bits, and it got 40 bits.
Unfortunately for us it doesn't look much like a mixer. There's not a knob or fader in sight.
This is where TotalMix appears on the scene. TotalMix provides a way to control the
hardware digital mixer built in to RME interfaces. TotalMix is not a software mixer -- it's a control panel for the hardware mixer implemented as DSP code on the FPGA.
If you have an RME PCI or PCIe card, there is a Linux equivalent of TotalMix available -- it's called
hdspmixer.
Note that this is the Linux equivalent of TotalMix, not TotalMixFX. On an HDSP9632, which is still manufactured twenty years later, there is no DSP compression or reverb, and TotalMix is there to provide virtual faders on a digital mixer.
For me RME was the budget option. A 9632 was £50 on ebay. Because PCI is becoming less common on motherboards, we are now in the situation where a second-hand 9632 is cheaper than the balanced, analogue breakout cable (~£60) that is required to have balanced (XLR) ins and outs. I already had a box that has four PCI slots in it, connected by a cable into a PCIe slot, so this was easy for me. If you want to try and get a PCI card working with a PCIe slot, careful research is required, particularly of the physical dimensions. Second-hand PCIe cards haven't gotten as low as £50 yet and they're quite rare on ebay. People who buy them appear to hang on to them.
I hardly use
hdspmixer because I can have the latency low enough to monitor through the computer. TotalMix is a solution from twenty years ago to the problem of latency, which was to accept latency and monitor through a different path. However if you're familiar with TotalMix, like
@sjzstudio, and want to work that way, I think that's fine.
Now some manufacturers use the absence of a mixer as a selling point like the
Presonus Quantum. Fast, eh? Blink and you'll miss it. Low latency might be more accurate. In 2022 it is possible to monitor through the computer, meaning that a mixer built into an interface is less essential.
But still we hear about the amazing RME proprietary drivers, and I think this is to do with the fact that USB is not really a pro audio standard. Some of the RME drivers get performance that is beyond what we would expect from USB 2.0. To achieve this RME treat the USB cable as a bit of wire, and completely re-write the USB audio protocol, implementing the USB controller on the FPGA.
It's unlikely we will ever get RME proprietary drivers for Linux, but it is likely that ALSA class compliant drivers are good enough.
