How to avoid microphone stutter? #1147

GeeTwentyFive · 2026-08-11T15:15:38Z

GeeTwentyFive
Aug 11, 2026

I had made a (facade-style) library on top of miniaudio some months ago, and I plan to update it in the future after I'm done with something else. The last thing I remember I was stuck on was the microphone da 8000 ta sounding stuttery when being recorded and then played back... and looking back at the code now, I still don't see why that is...
How would one avoid that?

this is the block of code which starts the microphone recording,

this is the block which gives it to the user,

and this is the block that plays it back

Answered by gitsult4n

Aug 15, 2026

The stutter isn't a device or latency setting — you're silently dropping frames on every ring-buffer wrap. There's also an unrelated use-after-free in the stream path that will bite you separately.

1. `acquire_write` / `acquire_read` only ever give you a contiguous run

This is the direct cause. From ma_rb_acquire_write:

if (writeOffsetLoopFlag == readOffsetLoopFlag) {
    bytesAvailable = pRB->subbufferSizeInBytes - writeOffsetInBytes;
} else {
    bytesAvailable = readOffsetInBytes - writeOffsetInBytes;
}

bytesRequested = *pSizeInBytes;
if (bytesRequested > bytesAvailable) {
    bytesRequested = bytesAvailable;
}

It clamps to the end of the buffer, never wraps. A single acquire/commit pair …

View full answer

gitsult4n · 2026-08-15T14:45:21Z

gitsult4n
Aug 15, 2026

The stutter isn't a device or latency setting — you're silently dropping frames on every ring-buffer wrap. There's also an unrelated use-after-free in the stream path that will bite you separately.

1. `acquire_write` / `acquire_read` only ever give you a contiguous run

This is the direct cause. From ma_rb_acquire_write:

if (writeOffsetLoopFlag == readOffsetLoopFlag) {
    bytesAvailable = pRB->subbufferSizeInBytes - writeOffsetInBytes;
} else {
    bytesAvailable = readOffsetInBytes - writeOffsetInBytes;
}

bytesRequested = *pSizeInBytes;
if (bytesRequested > bytesAvailable) {
    bytesRequested = bytesAvailable;
}

It clamps to the end of the buffer, never wraps. A single acquire/commit pair can hand you fewer frames than you asked for even when there's plenty of total space free — and ma_rb_commit_write explicitly rejects anything that would run past the end:

newWriteOffsetInBytes = (ma_uint32)(writeOffsetInBytes + sizeInBytes);
if (newWriteOffsetInBytes > pRB->subbufferSizeInBytes) {
    return MA_INVALID_ARGS;
}

Your capture callback does one acquire and throws the rest away:

void* mic_buffer_out; ma_uint32 nFramesToWrite = frameCount;
if (ma_pcm_rb_acquire_write(&mic_data_ring_buffer, &nFramesToWrite, &mic_buffer_out) != MA_SUCCESS) return;
if (frameCount < nFramesToWrite) nFramesToWrite = frameCount;
memcpy(mic_buffer_out, pInput, nFramesToWrite * ...);
ma_pcm_rb_commit_write(&mic_data_ring_buffer, nFramesToWrite);

When the write pointer is near the end of the buffer, nFramesToWrite comes back short and frameCount - nFramesToWrite frames of microphone audio are discarded. That's your stutter: a small gap, recurring on a fixed period. Note also that if (frameCount < nFramesToWrite) is dead code — acquire only ever clamps down, so that comparison can never be true. The guard you actually need is the opposite case, and it needs a loop, not a clamp:

mic_config.dataCallback = [](ma_device* pDevice, void* pOutput, const void* pInput, ma_uint32 frameCount) {
    const ma_uint32 bpf = ma_get_bytes_per_frame(pDevice->capture.format, pDevice->capture.channels);
    const ma_uint8* src = (const ma_uint8*)pInput;
    ma_uint32 remaining = frameCount;

    while (remaining > 0) {
        void* dst; ma_uint32 n = remaining;
        if (ma_pcm_rb_acquire_write(&mic_data_ring_buffer, &n, &dst) != MA_SUCCESS) break;
        if (n == 0) break;   // buffer genuinely full -> overrun, drop the rest
        memcpy(dst, src, n * bpf);
        ma_pcm_rb_commit_write(&mic_data_ring_buffer, n);
        src += n * bpf;
        remaining -= n;
    }
};

The n == 0 break is a real overrun and worth counting somewhere — if it fires you're not draining fast enough, which is a different problem from the wrap truncation.

PopMicrophoneData() has the same shape and needs the same loop; otherwise it returns a short read whenever the read pointer is near the end, even though more data is queued. Same again for the StreamDataSource read callback.

2. `RING_BUFFER_SIZE 1024` is too small

1024 frames at 48 kHz is 21.3 ms. miniaudio's default is ma_performance_profile_low_latency, i.e. MA_DEFAULT_PERIOD_SIZE_IN_MILLISECONDS_LOW_LATENCY 10 — about 480 frames per callback at your sample rate. So you wrap roughly every two callbacks and hit the truncation above constantly. If anything pushes you onto the conservative profile (100 ms = 4800 frames), a single callback is nearly 5× the whole buffer.

Size it in time, not in a magic number — half a second of slack costs nothing here:

#define RING_BUFFER_SIZE (DEVICE_IO_SAMPLE_RATE / 2)   // 500 ms

3. Use-after-free in `SoundStream` (separate bug, will cause garbage/crashes)

ma_data_source_init stores a pointer to itself:

pDataSourceBase->pCurrent = pDataSource;    /* Always read from ourself by default. */

But StreamDataSource_init initialises a local and returns it by value, and you then copy that into a heap allocation:

inline StreamDataSource StreamDataSource_init(...) {
    StreamDataSource out;
    ma_data_source_init(&base_config, &out.base);   // out.base.pCurrent = &out (stack!)
    ...
    return out;
}
...
this->stream = new StreamDataSource(StreamDataSource_init(_format, channels, sample_rate));

The heap object's base.pCurrent still points at the destroyed temporary. Every read goes through pCurrent, so you're dereferencing a dead stack address. Allocate first and initialise in place:

static void StreamDataSource_init(StreamDataSource* out, ma_format format, ma_uint32 channels, ma_uint32 sample_rate) {
    ma_data_source_config base_config = ma_data_source_config_init();
    base_config.vtable = &stream_source_vtable;
    if (ma_data_source_init(&base_config, &out->base) != MA_SUCCESS) ERROR("...");
    out->format = format; out->channels = channels; out->sample_rate = sample_rate;
    if (ma_pcm_rb_init(format, channels, RING_BUFFER_SIZE, NULL, NULL, &out->pcm_buffer) != MA_SUCCESS) ERROR("...");
}
...
StreamDataSource* s = new StreamDataSource{};
StreamDataSource_init(s, _format, channels, sample_rate);
this->stream = s;

4. Two smaller things in the stream read callback

void* buffer_in; ma_uint32 nFramesToRead = frameCount; *pFramesRead = frameCount;
result = ma_pcm_rb_acquire_read(..., &nFramesToRead, &buffer_in); if (result != MA_SUCCESS) return result;
MA_ZERO_MEMORY(pFramesOut, frameCount * ...);

On the failure path you've already set *pFramesRead = frameCount but return before zeroing pFramesOut, so the engine plays whatever uninitialised memory was in that buffer. Set *pFramesRead = 0 before the early return.
On the success path you always report a full read and pad with silence. That's a reasonable choice for a live stream, but it means an under-filled buffer is indistinguishable from real audio — you'll hear it as clicks rather than as an underrun you can detect. Worth counting the shortfall so you can tell "producer is behind" apart from "genuinely quiet".

Fixing #1 and #2 should clear the stutter on its own; #3 is the one to fix before it turns into an intermittent crash.

2 replies

GeeTwentyFive Aug 15, 2026
Author

HOLY CRAP bro you didn't have to go this far for some one-off question but YOU WENT ABOVE AND BEYOND

THANK YOU!!! ❤️❤️❤️

Humans have limited resources (energy, motivation, time, etc.), so take care of yourself man; don't splurge all of it on other people and leave yourself with nothing left ❤️

gitsult4n Aug 15, 2026

Ha, thank you — that's very kind of you, and noted about looking after myself 🙂

Honestly your question was a pleasure to dig into: you linked the exact three blocks rather than a whole repo, so the reading was targeted. That's most of why it went deep. Good bug reports get good answers.

If you only get to one thing, make it the acquire/commit loop — that's the stutter. The pCurrent dangling pointer is the one I'd fix next though, because it won't show up as a clean symptom; it'll be an occasional crash or garbage audio months from now that looks unrelated to anything you changed that day.

And do shout if the loop doesn't fully clear it. If a gap survives with a half-second buffer, that points at the consumer side rather than the wrap, and ma_pcm_rb_pointer_distance() logged once a second is usually enough to tell which — steadily climbing means the producer is outrunning you, repeatedly hitting zero means you're starving.

Good luck with GAudio 👍

Navigation Menu

Repository navigation

How to avoid microphone stutter? #1147

Uh oh!

{{title}}

Uh oh!

Replies: 1 comment 2 replies

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

How to avoid microphone stutter? #1147

Uh oh!

GeeTwentyFive Aug 11, 2026

1. acquire_write / acquire_read only ever give you a contiguous run

Replies: 1 comment · 2 replies

Uh oh!

gitsult4n Aug 15, 2026

1. acquire_write / acquire_read only ever give you a contiguous run

2. RING_BUFFER_SIZE 1024 is too small

3. Use-after-free in SoundStream (separate bug, will cause garbage/crashes)

4. Two smaller things in the stream read callback

Uh oh!

GeeTwentyFive Aug 15, 2026 Author

Uh oh!

gitsult4n Aug 15, 2026

GeeTwentyFive
Aug 11, 2026

1. `acquire_write` / `acquire_read` only ever give you a contiguous run

Replies: 1 comment 2 replies

gitsult4n
Aug 15, 2026

1. `acquire_write` / `acquire_read` only ever give you a contiguous run

2. `RING_BUFFER_SIZE 1024` is too small

3. Use-after-free in `SoundStream` (separate bug, will cause garbage/crashes)

GeeTwentyFive Aug 15, 2026
Author