Hope you're not planning to play with a backing track, ASIO4ALL notoriously does not play nice with multiple audio sources. It's almost like someone wanted to backport the horrors of ALSA to Windows because they missed how annoying it was having a single pair of inputs and outputs.
>ASIO4ALL notoriously does not play nice with multiple audio sources.
Yep, that's because Asio4all uses WDM-KS and WDM-KS since Vista doesn't support multiple sources.
Actual ASIO drivers made by sound card manufacturers usually don't have this limitation, as long as you keep the same sample rate everywhere. But it can also vary depending on who made the driver and/or on whether the source apps are using ASIO or a mix of ASIO and WDM/WASAPI. Getting low latency audio to work nicely on Windows can be messy (compared to macOS, at least).
I seriously doubt it. I don't think it's possible for shared WASAPI to go below 20-30ms. How are you measuring it? Input, output or round-trip?
For easy RTL measurements, you can use this: https://oblique-audio.com/rtl-utility.php
Oof, I forgot what thread I was in, because I just meant the buffer size, not the round-trip latency or not even the one-way latency to audio output. Not sure why I said "latency" as that's plain wrong, especially when we're talking from capture in this case.
It's just that I'm more focused on soft synths, and I can get a clean signal out of 64-samples buffers. Granted, that's not what I'd use with any realistic processing (for instance, I use Reaper at 128spl@48k).
While I haven't measured end-to-end yet, I do hope it stays below 20ms. I'm working on a synth-powered rhythm game, and the whole reason I chose to stick with plain WASAPI was to avoid requiring users to install extra drivers and because of Windows 10's low latency stack, with its advertised 0ms capture and 1.3ms output overhead on top of application and driver buffers.
Update: I ran RTL on the budget 2012 desktop and got worse results than I expected at 18ms@128spl for shared-mode WASAPI [1]. For some reason, I couldn't select smaller buffers. On the same hardware, exclusive-mode WASAPI managed 12.25ms@128spl, and ASIO4ALL managed 12.5ms@64spl and 15.1ms@128spl.
Thanks for testing. That 18ms result is actually much better than I expected for a shared mode. It got me curious, so I tried it and I was able to replicate it with my Realtek (I got 19ms). I'm still a bit skeptical about its real-world use, because I've experienced some garbled/distorted audio with some low latency modes. I also can't find that mode in Reaper, which usually has everything. Still, it looks promising.
Since I had a bunch of software open and the system had been online forever, I restarted and tested again — turns out it squeezed a couple of ms to ~16ms on shared-mode.
By the way, I believe the low latency stack is enabled system-wide, so Reaper should already be using it.
For what it's worth, on my game I've been piping a SunVox instance to a 128-samples shared-mode WASAPI stream and haven't encountered distorted audio, yet.
At the end of the day, I guess I would indeed default to recommending WASAPI unless one has hardware with great ASIO drivers.
You might want to check out audio processing on Linux with a (soft) real-time kernel. The choice of plugins is limited, but it is reasonable to run a 5 man band (including three guitar amp modelers and voice processing) at 2.8 ms (internal) round-trip latency (plus some ms for AD/DA) on a "some what beefy but still just a laptop"-laptop.
Actually, the RT_PREEMPT stuff gives you worst-case blips around the 100-300 microsecond mark, and if it's just audio with remotely tolerant handling of buffer under/overrun, you can ignore those and use the more normal latency ceiling around 20-50 microseconds.
Note: 192 kHz is 5.2 microseconds/sample, 48 kHz is 20.8 microseconds/sample. The 15 cm distance between the ears takes around 100 microseconds to traverse (at the higher speed-of-sound in the head, vs. free-air).
The 1m distance of air for close-by human 1:1 talking takes a full 3 milliseconds to traverse.
There is a non-profit [0] with hard-realtime applications (including CNC) that runs a few racks of systems with latency monitoring.
For example, the blue rack3slot0 line [1] is a histogram for an almost-standard distribution kernel on an IvyBridge Xeon-E3 running a thread with timer interrupts every 200 microseconds for about 5.5 hours (100 M times, specifically), and recording the latency of that interrupt.
As one can see, there were about 20 at-or-above 20 microsecond delay, and even then just barely over.
With remotely decent under/overrun hiding, 10 microsecond latency should be easily usable.
And yes, those systems had background load at normal priority and this realtime thread at high priority:
> Between 7 a.m. and 1 p.m. and between 7 p.m. and 1 a.m., a simulated application scenario is running using cyclictest at priority 99 with a cycle interval of 200 µs and a user program at normal priority that creates burst loads of memory, filesystem and network accesses. The particular cyclictest command is specified in every system's profile referenced above and on the next page. The load generator results in an average CPU load of 0.2 and a network bandwidth of about 8 Mb/s per system.
Not entirely sure what you are getting at, I am guessing "10 ms latency is good enough for audio"? Plus "normally we are so far away from the speaker that it does not really make a difference"?
That figure is thrown around a lot and is definitely grounded in some solid research ... just ... lower latency numbers (in jackd) "feel" better when playing guitar. There is a lot of subjectivity in the guitar playing world and I am definitely not immune to that.
So ... 2.8 ms round-trip time in jackd plus 1-2 ms for AD/DA conversion plus 3 ms that the sound takes to travel from the speaker to my ear (plus any latency that the brain needs to process the sound). 2.8 + 2*1-2 + 3 already gets us very close to 10 ms.
No idea what I am getting at here, but I am on my third generation of modelling amps (cheap M-Audio BlackBox, POD X3 Live, now Guitarix) and while I never really had an issue with the latency ... I feel like I probably would if I went back to a previous generation.
There is a lower threshold beyond which you won't feel the difference anymore.
Also, by replacing a speaker with headphones, there is enough latency budget from that that can be spent on lightspeed delay for 100+km distance, if optimizing the audio stack for deep-sub-millisecond delays using RT_PREEMPT.
Yes, this precludes USB2, but modern computers have quite decent on-board audio codecs (aka A/D + D/A engines) that end up connected to the southbridge and are accessed via PCIe. That has sub-microsecond latency between the digital side of the A/D + D/A converters and the CPU cache.
I guess I mostly just wanted to say "RT_PREEMPT reduces jitter enough to allow sub-millisecond AD->jackd(mixer only)->DA without much effort using modern onboard audio", and to show that is truly little in sound wave path length.
"the issue" refers to the audio latency of speakers, I assume? If not, please elaborate; my understanding of the matter in practical/human terms is fairly fuzzy due to most of this being very domain-specific knowledge I haven't been in the right places for.
Oh, I know USB-attached-SCSI (the good USB3 storage protocol) is nice in latency due to actually exploiting the dedicated TX/RX lanes for latency benefits. It just shoves command packets towards the drive, and receives response packets when the drive has them ready.
However, USB still has comparatively severe driver overhead due to the MMIO-level protocols, to a similar (but iirc worse) extend as AHCI (with NVMe being the better replacement).
My main platform is Linux :) on it I run a RME Multiface II ; with it I can go down to 32 samples of latency and still do some useful stuff without even using a RT kernel (can only go down to 64 in Windows w/ ASIO).
Recently I had a cool art project where we ran 48-channel ambisonic sound spatialization + live video effects, all that from a single Dell laptop sending audio through AES67 (so Ethernet) and video on 3 1080p outputs. Linux is incredible with the right hardware !
(shameless self-promotion: this was with https://ossia.io score :-))
Oh, so this is like a web browser thing?
> Click here to download FarPlay
Oh, so I _do_ need to install FarPlay. Just not any software that's a third party besides FarPlay. Which wouldn't make any sense.