ASIO capture: input ring overflow drops a raw float count → all channels permanently rotated

[TommiIversen]

Hi ModernMube,

Following up on #37 — multichannel ASIO capture has been running nicely in my recording
setup on the 4.0 release.
I've now hit one subtle thing in production that I think I've tracked down to the input ring buffer.

Environment

• OwnAudioSharp 4.0.1 (NuGet), .NET 10, Windows 11 (x64)
• RME UFX III, 12-channel ASIO capture at 48 kHz / F32

What I saw

After a busy process start, the whole capture was shifted by one channel: the audio coming
out on slot n was actually physical input n+1 (a mic patched to input 10 showed up on
input 9's slot, the last slot went silent). It stays that way until the stream is
restarted. Nothing reports an error — Receives() keeps returning healthy counts, so from
the consumer side it's undetectable.

What I think happens (reading the 4.0 source)

If I'm reading RustAudioEngine right:

• _inputCallback does _inputRing?.Write(args.Buffer) and ignores the return value —
  the comment says "on overflow we drop rather than block the audio thread", which is a
  sound policy in itself.
• LockFreeRingBuffer<T>.Write copies Math.Min(data.Length, WritableCount) floats and
  silently discards the rest. The ring has no concept of frames, and WritableCount is
  capacity - Available - 1 (one slot burned to tell full from empty), so the count that
  fits is almost never a whole number of frames.
• So a single overflow where dropped % channels != 0 leaves a mid-frame gap in the
  stream, and any consumer slicing fixed-size interleaved blocks out of Receives() is
  rotated from that point on — permanently and silently.

The trigger is just the consumer stalling longer than the ring depth (~8 engine buffers).
The window between Start() and the first Receives() call on a loaded machine is
already enough — that's exactly my startup case.

Repro sketch

1. ASIO, EnableInput, N ≥ 2 channels, a distinct tone per physical channel.
2. Start(), then wait ~500 ms before the first Receives() (simulates a busy startup).
3. Consume fixed-size interleaved blocks: the tones sit on rotated slots until restart.

The output side has the mirrored hazard

Send itself looks safe (it blocks and retries partial writes), but _outputCallback
does _outputRing?.Read(args.Buffer): if Available isn't frame-aligned at callback time
(an underrun racing a partial producer commit), the read ends mid-frame and the
continuation lands on channel 0 of the next period's buffer — the same rotation, on
render. The trigger window is much narrower, but it's the same class of defect.

One possible fix

From the outside it looks like the lock-free design and the drop-on-overflow policy could
both stay as they are — one idea would be to clamp the two RT call sites to whole frames:

• Input: on overflow, round the written count down to a multiple of the channel count
  (dropping audio on overflow seems fine and unavoidable; it's only the alignment loss
  that hurts).
• Output: round the callback's read down to a multiple of the channel count and leave
  the partial frame in the ring for the next period.
• And maybe a dropped-frames counter surfaced through the engine, so hosts can report
  overflow instead of guessing.

If the callbacks clamp, the ring itself could stay frame-agnostic — but there may well be
a better place to solve this that I'm not seeing.

I've worked around it on my side for now (a dedicated drain thread started right after
Start(), feeding a frame-aligned buffer), so no urgency — but the in-engine fix would
make the capture path safe by construction. Happy to submit a PR for this if you'd take
it.

Cheers,
Tommi

[ModernMube]

Hi Tommi!

Upload your implementation of the suggestion and I will take a look!
Thank you for your work!

I have examined the problem and I would like to clarify the following:

The output page is indeed a bug of the same class, but I would rearrange the argument a bit: the "partial commit during underrun" is not the rare part — Send's spin-loop (:319-330) commits partial writes even in normal operation with a full ring, and they are also not frame-aligned due to the above -1. It is rare for this to coincide with an underrun. The end result is the same, only the probability justification is different.

In Rust-native mode, no one reads this ring (see ReleaseInput's comment), the bug does not occur there — this explains why it has not failed so far.

I have checked the problem and your suggested fix and I suggest the following:

The direction is good, but I would change its location. Clamping the two call sites works, but the convention remains: the next caller can still mess it up. Since the only consumer of LockFreeRingBuffer is RustAudioEngine, it can be solved cheaply by the following construction:

1. Optional frameSize in the ring ctor, and Write/Read rounds down to a multiple of it. Both directions are improved in one place, WritableCount/Available can also be adjusted. Additive public API change → PublicApiGenerator approval file needs to be updated.
2. The rounding on the Send write side is more important than the clamp on the output callback read side — if the producer never commits a half-frame, Available will never be inter-frame, and there is nothing to save on the callback side. (No livelock: the capacity is much larger than a frame.)
3. It is also worth rounding down the reading of Receives, because the caller can give an arbitrary long span.
4. The dropped-frames counter is a good idea; in the callback, a simple int increment + Volatile.Read is enough for the query, without Interlocked and allocation, so it remains RT-safe.

If you can wait a few days, I'll do it and upload the fix!

[ModernMube]

Hi!

I uploaded the fix to nuget!
The bug was a bit deeper than it first appeared, but I hope it works. Unfortunately I can only test ASIO to a limited extent!
Thank you for your contribution!

[TommiIversen]

Hi ModernMube,

Thanks for the quick fix!

I've removed my workaround and upgraded to 4.0.4, so my capture path now runs directly against your ring.

I also ran the repro from this issue against my RME: a ~2.5 s stall right after Start() forced a real overflow (drop counter 0 → 24576 frames), and every Receives() return across it stayed an exact multiple of the channel count - no reads off a frame boundary.

So the fix works as promised. This can be closed from my side. Thanks again!

Cheers,
Tommi