dechamps
commented
2 years ago SOMEHOW has negative latency ??? ie sample occurs roughly 34ms BEFORE the metronome click - NO IDEA how this is happening!
I don't know anything about Ableton, but I can hazard a guess. ASIO drivers can report their estimated latencies to the host application (either on request, or as a timestamp estimate on every buffer being passed back and forth). What I suspect is happening is that Ableton is using this data to automatically compensate for the latency announced by the driver. That is, it might be automatically shifting the displayed waveform to the time at which it thinks the audio signal was actually recorded. (A similar process might take place on the playback side, shifting the time at which Ableton will beat the metronome.)
If that is the case, then that would completely explain how you might observe seemingly negative latencies: the FlexASIO WASAPI backend might have an issue where it might be overestimating the latency in this case, leading to Ableton shifting the waveform too far to the left to compensate, and you end up with an audio event that seemingly occurred before the trigger. Causality was not violated - it's just the display that's misleading.
Still assuming that my hypothesis is correct, this would mean that in your experiments you were not measuring actual latency - you were instead measuring how well the driver-advertised latency matches the actual latency. Which, granted, is still somewhat useful, but presumably that's not what you were looking for...
This would also explain why your measurements appear perfect for ASIO4ALL and Focusrite: it could very well be that these drivers estimate their own latencies correctly, so it looks like they have near-zero latency in Ableton, but in reality that just means Ableton correctly realigned their waveforms to compensate for the actual latency.
Now, I'm not surprised that FlexASIO latency estimates might be off. The PortAudio code that computes them could probably use some love and it's probably wrong in many cases. It's a bit tricky to get these numbers right though, because in order to fix them we'd first need to measure what the actual latency looks like in a variety of scenarios, and that is made harder by the fact that we need to estimate the output latency independently from the input latency. A loopback experiment can be used to measure the total latency, but says nothing about the breakdown between output and input latency. It's a solvable problem of course, but it's not trivial.
As for the glitches/pops/scratches, well, sadly that's not too surprising when trying to get latencies as low as possible, because at some point you hit the scheduling deadline limits of the backend. Now, I suspect that there as well the PortAudio backend code could likely be improved to allow for smaller glitch-free latencies, but again this requires someone to sit down and investigate this stuff in depth (which would also likely involve writing a custom test framework for experiments and measurements).
I would love it if someone sufficiently skilled and motivated could tackle these issues, do the relevant in-depth experiments/measurements/testing, investigate the relevant PortAudio backend code, and make the necessary fixes. Sadly I lack the time and motivation to do this kind of work: even though I wrote the whole thing, I actually only use FlexASIO in a very basic capacity that does not require low latencies nor reliable latency estimates.
danryu
uzrnme
This is an attempt to get reliable low-latency performance from FlexASIO, using generic laptop hardware, which will probably be the use case for most people needing to use a universal ASIO driver.
Hopefully this will be useful as a general comparison for different configurations. In particular, there is a strange issue with WASAPI Exclusive mode which I would like to address/resolve! Please see the test results below.
The tests cover:
across a few representative configurations. I also attach a zip file with the audio from each of the tests, to illustrate my descriptions. asiotest.zip
Test setup:
TL;DR:
1) FlexASIO WASAPI Shared
End result:
2) FlexASIO WASAPI Exclusive - 512 Buffer, suggested 0.0s
End result:
3) FlexASIO WASAPI Exclusive - 1024 buffer, Suggested 0.01
End result:
4) FlexASIO WDM-KS 512
Note: FlexASIO will NOT initialize with
suggestedLatencySecondssetEnd result:
5) FlexASIO WDM-KS 128 buffer
End result:
6) FlexASIO WDM-KS - buffer 64
End result:
7) ASIO4ALL - 512
Settings:
End result:
8) Focusrite ASIO - 32
Interface: Scarlett 2i4 Mic: SM57
End result: