Tomás Mulcahy wrote:
CS70 wrote:Eh. The issue is that there is no such thing on Windows.
There is, as already mentioned. Twice. ASIO4all can do it. It's hacky but it's there.
CS70 wrote:And even in Mac OS, I guess that without hardware clocking (as it would be on USB keyboard) there would be clock drift between the various interfaces and probably some software compensation..
You don't need a hardware clock. The Audio MIDI Setup utility lets you select drift correction for each device. Effectively the same thing. And it works too.
These are both bizarre statements. I wouldn't really be replying but someone reading this might conclude that Asio4All and similar are a solution, and waste time.
So: first we're talking Windows, not Mac. There is no Audio MIDI Setup utility on Windows
. The differences don't stop there - more on that later.
Asio4All wraps over WDM and the full Windows audio stack - plus of course the translation layer, which is at least two additional memory copies for each buffer cycle. Latency is in the vast majority of case simply unacceptable for any kind of performance recording. Asio4All is not a solution for recording
- one interface or many interfaces. Emphatically so. Unless one records one note at a time. Then it works.
It is a good solution for playback when for some reason one has an ASIO-only application but no ASIO device connected. There are some specialized apps - especially open source - which may not yet have implemented WASPI exclusive, and then Asio4All is a good playback crutch. More time goes by, more apps will expose WASAPI Ex and there will be less and less need for Asio4All (or ASIO, for what matters).
When it comes to "drift correction", it is just a fancy name for an algorithm that attempts to guess and sync signals from several parallel isochronous transfers. First the computer must identify a precise clock. This is already hard with one
transfer and - out of the three ways it can be done - the one which has a chance to work well enough for studio quality is called "asynchronous" synchronization mode (as opposite to "synchronous" and "adaptive" - the USB spec is your friend); then the algorithm has to identify the clock of the external sources and decide how to compensate for the differences. Which change over time.
In Macs, assuming USB is involved and not another protocol, that has a chance to work because the specification of the USB controller on the computer is well known (there are only so many models), and the same class-compliant driver is used in the OS, meaning the interface manufacturer will have a clear idea on what the OS will do and the timings involved and will, hopefully, write the microcontroller's firmware accordingly. Still, I wouldn't want to count on it - a slight change in the OS driver or a little misstep in the interface programming can throw things out of the window.
In Windows, both the sink and the source will have one out of a large number of possible microcontrollers, each with their own driver and timing, not counting that you have USB controllers both in the southbridge or similar control hub, plus additional ones in the motherboard. The chances that a reliable clock can be extracted by these is the same as winning a lottery. It may happen, but it mostly doesn't.
So, no, Asio4all does not generally work well for recording performances, and the chances that its device aggregation works reliably are, at best, very slim.
As a note: nothing bad to say about Asio4All per se. It does what it's designed to do and it does it well. So does a crutch. The mistake is trying to run with it.