Software ASIO Setup

[7cff]

I'm helping a group of musicians set up Jamulus. It works flawlessly on Linux via JACK/Pipewire routing and with a dedicated audio interface on Windows (delays of ~20ms), but I've not had success with software ASIO solutions like ASIO4ALL and KoordASIO. With ASIO4ALL, I've been getting delays of 1000ms and with KoordASIO, it's down to about 120ms. Anyone who's familiar with the Windows sound stack, what's going on here?

[mcfnord]

🤖 AI: Both numbers have an explanation, and they are different explanations. Jamulus folds whatever ASIOGetLatencies returns straight into the Overall Delay estimate, so that readout inherits whatever the driver chose to say. Measured on a Windows 11 box at 48 kHz, one Focusrite interface, 64-sample buffers, the three drivers disagree completely about themselves:

driver	reported in+out	note
ASIO4ALL v2	128 samples, 2.667 ms	exactly the buffer each way, at every size offered
Focusrite USB ASIO (native)	382 samples, 7.958 ms	its real converter and USB pipeline
KoordASIO 2.3.0, exclusive	2192 samples, 45.667 ms	same interface as the row above
KoordASIO 2.3.0, shared	2239 samples, 46.646 ms	0.98 ms from exclusive

So the 120 ms is ordinary arithmetic: 46.6 ms of sound card plus both jitter buffers at maximum is 125 ms before ping. Raising KoordASIO's buffer only makes it worse, which makes roughly 46 ms its floor on that hardware — and exclusive mode buys about 1 ms, not the 5 ms against 20 ms reported in 2021.

The 1000 ms is the opposite problem: ASIO4ALL claims 2.667 ms, so nothing in the delay estimate can produce it. That figure is coming from outside the sound-card term — worth checking the reported Overall Delay against what is actually audible, since ASIO4ALL sits on the Windows backend — as does the Steinberg driver — and counts only its own two buffers, never the stack underneath.

One practical consequence: KoordASIO advertises a fixed buffer size, so its own setting overrides the Jamulus dropdown entirely. ASIO4ALL advertises 64 upward and honours it, so there the Jamulus capture-buffer setting does apply.

(The ASIO4ALL row was measured on a generic USB audio device, not on the Focusrite — corrected in a comment below.)

[7cff]

So is the implication that the KoordASIO number correct while ASIO4ALL is reporting an incorrect value? Are there other reports of this actually happening? This is certainly the first I've heard of ASIO4ALL reporting such an outlandish number.

To be clear, the number of samples we're using for these ASIO drivers is in the 64-512 range, so the buffer size should not be the cause of the issue.

Have you worked with these ASIO solutions personally, and does this actually match your experience?

[mcfnord]

I use AI extensively here. Here's my typed reply, plus a followup from the AI.

My own experience with KoordASIO is none at all (interested to learn it exists). I used ASIO4ALL 5 years ago, and last month my AI testbed helped discover and fix some bugs in our usage of ASIO4ALL. I only vaguely understand the issues being discussed here.

To author that comment, I asked an Anthropic model (Fable or Opus) how it would respond to your message. I've also set it up to test every claim it wants to make, and then watched and approved as it set up the KoordASIO driver and others on my weak Windows computer with the Focusrite connected.

This requirement I've established--that every claim be tested--has dramatically reduced the amount of errors produced under my name using AI, and it would surprise me if the post contains substantial errors (it has apparently made one correction), but I can't vouch for the information in quite the same way as someone who has hands-on experience with the subject. I'd eagerly consider evidence that contradicts these claims, though again I'd really just shove it in the AIs face and demand answers.

---

🤖 AI reply starts here: Correction first, because it is the row being asked about. That table's ASIO4ALL figure was not measured on the Focusrite. The header scoped all three rows to one interface; ASIO4ALL was running on a different, generic USB audio device. On the Focusrite it reports 16.833 ms at a 64-sample buffer, not 2.667 ms — so "exactly the buffer each way" describes that other device, not the driver.

To which number is right: neither was established, because both were the driver describing itself. A round trip is measurable independently. An impulse goes out an ASIO output and comes back through the interface's own loopback, counting samples.

Native Focusrite ASIO, buffers of 64, 128, 256 and 512: the self-report exceeds the measured round trip by 25 to 31 samples at every size. That driver is accurate to well under a millisecond.

ASIO4ALL, same interface, same loop, 64-sample buffer: reported 808 samples, measured 9981 samples. 16.833 ms against 207.938 ms. The native driver on that identical hardware measures 7.438 ms. Sweeping ASIO4ALL's own latency-compensation setting moves its reported figure by 404 samples while the measured round trip stays within 0.902%, so the figure Overall Delay relays is tracking a stored setting rather than the path.

Practical consequence: the sound-card term of that readout is 191.105 ms short of the path it names.

Every run is in the log — 14 of them, including the two arms that produced nothing.

What it does not settle:

• The loop is the interface's internal digital loopback, so the converters are outside it. Every figure above is a lower bound on the analog round trip.
• KoordASIO is still unmeasured. Its capture is the analog input, so the impulse never returns to it. Its 46.646 ms is still only its own account of itself, and a patch cable is what closes that.
• ASIO4ALL was pointed at the Focusrite by writing its device-enable registry key, not through its control panel. The compensation sweep bounds how much that can matter; other profile fields went unswept.
• One interface, one machine. Nothing here makes 207.938 ms ASIO4ALL's number anywhere else.
• That floor is measured, not diagnosed. Which layer contributes it is open.
• The harness is a test host, not Jamulus.

[ann0see]

The real fix is unfortunately not free. But you should try to get a cheap USB mic or interface since windows is finicky. The support cost is probably higher than getting good hardware. Otherwise, you could of course switch to dedicated Linux installs (or USB boot).

See: https://jamulus.app/kb/2021/01/05/Jamulus-Sound-Devices.html

[7cff]

Unfortunately that interface needs to be imported from Europe for us, and our stupid tariffs mean the cost is higher.

I'll leave this discussion unsolved for now to see if anyone chimes in, and will circle back to mark as solved once we find a solution that works and can hopefully be recommended on the Jamulus KB for future readers.

[rdica]

Have you looked at jack for Windows, it inclludes an ASIO driver. Also, Reaper DAW (freely available, Win/OS X/Linux compatible) includes one that provides ReaRoute but I think the caveat with its use is the requirement to run Reaper and have it configured to utilize the audio routing you desire. There are Youtube videos detailing that process.

[ann0see]

Unfortunately that interface needs to be imported from Europe for us, and our stupid tariffs mean the cost is higher.

There should probably be similar ones for you from an US manufacturer or similar then. I don't know the market over there but I find it very likely that you'll succeed.

[rdica]

Behringer umc202hd has a native ASIO driver for Windows and is relatively inexpensive in the US at $85-$90.

[7cff]

I've tried JACK for Windows, but its ASIO driver has a similar latency to KoordASIO. Still unsure why ASIO4ALL has a 1000ms latency.

We're trying a couple of interfaces like the Behringer one (one of our musicians has actually opted for a Fender Studio one) and will report back.