Possibly for two reasons: a) RME interfaces transmit more channels, with all channels always being transmitted regardless of whether they are in use or not, and b) RME drivers achieve lower latency, which means the computer’s configuration needs to be perfectly aligned, and USB transfer modes must operate flawlessly.
As for Apple, their track record with USB has been less than stellar. There have been hardware and driver issues that Apple initially ignored or delayed addressing, attributing them to "USB 3rd party devices." These issues were only resolved in the drivers after approximately three-quarters of a year, following coverage in the trade press. A few years ago, during the introduction of a new communication chip, USB implementation problems arose, which could only be resolved by purchasing Thunderbolt docks with standard USB3 chips. Despite Apple’s relatively narrow hardware lineup, it is by no means a "perfect world" either.
However, this issue is not exclusive to RME. For decades, companies have offered turnkey systems that are rigorously tested for professional audio (and video) applications—not just for RME components.
Take a look at device lists that rank how laptops perform in terms of DPC latency:
https://www.notebookcheck.com/DPC-Laten … 375.0.html
In this area, only a few systems fall significantly below the critical threshold of 1000 microseconds, which is necessary to handle near-realtime demands for audio processing. Staying well below this limit is essential to avoid audio dropouts under high loads or with smaller buffer sizes.
The issue extends to desktop systems, which present even greater hardware diversity and driver variations.
Hardware must be paired with drivers that don’t occupy CPU cores for extended periods. Audio processes waiting for cores to become available shouldn’t face excessive delays, as this can lead to audio dropouts. While larger buffer sizes can partially offset this, they also increase audible latency for audio transport over digital interfaces (USB, FW, TB).
No mainstream operating system is a real-time operating system. To ensure data integrity, drivers must not be interrupted by the OS’s process scheduler; only the driver itself can release the CPU after its programmed interval. Unfortunately, not all driver developers adhere to the necessary programming conventions. Since audio is a niche market, these aspects are rarely tested. Manufacturers are primarily motivated by benchmark results, where everyone aims to excel. This often leads to longer CPU occupation times for better scores. While this is not an issue for benchmarks or standard applications, it becomes critical for real-time audio processing.
Fortunately, many users don’t encounter major issues, but with the wide variety of hardware combinations, it’s not guaranteed that everything will align perfectly for real-time audio demands.
This longstanding issue is why, despite increasing CPU performance, companies still specialize in providing turnkey solutions for audio processing. Professional recording studios don’t have the time or resources to address these challenges themselves.
Even for Apple, audio processing remains a niche segment. Otherwise, past issues would not have occurred. Unfortunately, manufacturers don’t conduct thorough testing in this area. For Apple, all recording interfaces are considered "3rd party interfaces" by default, instead of recognizing the reality that USB is a multi-purpose interface. Apple also has a responsibility to ensure that its drivers and USB controllers adhere strictly to USB standards and to resolve issues promptly.
Regarding DPC spikes, I haven’t tested it myself, but I frequently read that nVidia GPUs can cause issues for audio processing. AMD cards may not exhibit these problems to the same extent.
In summary, audio processing with near-realtime requirements can be a challenging field. Even powerful CPUs and good benchmark results are no guarantee of excellent audio processing performance.
For maximum reliability, consider investing in a turnkey system for audio processing from a specialized company.
This all is not RME specific...
BR Ramses - UFX III, 12Mic, XTC, M-1620 Pro D, RayDAT, ADI-2 Pro FS R BE, X10SRi-F, E5-1680v4, Win10