Pretty bad latency regardless of config / platform

[almostobvious]

So I've got a simple setup akin to this example, and tested on Windows(wasapi) and on Raspberry PI (pulseaudio).

In both cases latency is so bad it's audible. If playing guitar or singing, sound is so late it really makes it hard to even play or sing. I didn't measure but it's well over 100ms, perhaps over 200ms.

I've experimented with various periodSizeInFrames settings all the way down to 128 (2.6 ms) - which interestingly don't seem to have effect - it always ends up using 3 buffers of 441 samples each - unless I request bigger buffers than this (e.g. periodSizeInMilliseconds = 20 results in Buffer Size: 882*3 = 2646). On Windows, I've also tried wasapi.noAutoConvertSRC without improvement (regardless of the sample rate).

Also tried config.performanceProfile = ma_performance_profile_low_latency; which perhaps helped a little, but there is still quite audioble delay, I think still well over 100ms.

Am I correct in understanding that periodSizeInFrames seems to be how much is added to the base latency of the backend, and does not set overall latency?

Is this a platform / backend limitation? Are there any other parameters that can reduce latency?

Just to note, using ASIO, my hardware on windows comfortably maintains latency with 256 frames (~5ms) assuming I don't stack up too many plugins.

Thanks in advance. Some debug output below.

DEBUG: System Architecture:
DEBUG:   Endian: LE
DEBUG:   SSE2:   YES
DEBUG:   AVX2:   NO
DEBUG:   NEON:   NO
DEBUG: [WASAPI] Trying IAudioClient3_InitializeSharedAudioStream(actualPeriodInFrames=441)
DEBUG:     defaultPeriodInFrames=441
DEBUG:     fundamentalPeriodInFrames=441
DEBUG:     minPeriodInFrames=441
DEBUG:     maxPeriodInFrames=441
DEBUG: [WASAPI] Using IAudioClient3
DEBUG:     periodSizeInFramesOut=441
DEBUG: [WASAPI] Trying IAudioClient3_InitializeSharedAudioStream(actualPeriodInFrames=441)
DEBUG:     defaultPeriodInFrames=441
DEBUG:     fundamentalPeriodInFrames=441
DEBUG:     minPeriodInFrames=441
DEBUG:     maxPeriodInFrames=441
DEBUG: [WASAPI] Using IAudioClient3
DEBUG:     periodSizeInFramesOut=441
INFO: [WASAPI]
INFO:   Line (9- AG06/AG03) (Capture)
INFO:     Format:      32-bit IEEE Floating Point -> 32-bit IEEE Floating Point
INFO:     Channels:    2 -> 2
INFO:     Sample Rate: 44100 -> 44100
INFO:     Buffer Size: 441*3 (1323)
INFO:     Conversion:
INFO:       Pre Format Conversion:  NO
INFO:       Post Format Conversion: NO
INFO:       Channel Routing:        NO
INFO:       Resampling:             NO
INFO:       Passthrough:            YES
INFO:       Channel Map In:         {CHANNEL_FRONT_LEFT CHANNEL_FRONT_RIGHT}
INFO:       Channel Map Out:        {CHANNEL_FRONT_LEFT CHANNEL_FRONT_RIGHT}
INFO:   Line (9- AG06/AG03) (Playback)
INFO:     Format:      32-bit IEEE Floating Point -> 32-bit IEEE Floating Point
INFO:     Channels:    2 -> 2
INFO:     Sample Rate: 44100 -> 44100
INFO:     Buffer Size: 441*3 (1323)
INFO:     Conversion:
INFO:       Pre Format Conversion:  NO
INFO:       Post Format Conversion: NO
INFO:       Channel Routing:        NO
INFO:       Resampling:             NO
INFO:       Passthrough:            YES
INFO:       Channel Map In:         {CHANNEL_FRONT_LEFT CHANNEL_FRONT_RIGHT}
INFO:       Channel Map Out:        {CHANNEL_FRONT_LEFT CHANNEL_FRONT_RIGHT}
DEBUG: [WASAPI] Capture Flags: 1

[mackron]

That kind of latency is definitely not normal, but the info captured by the logs looks totally fine. miniaudio will default to 10ms which is what you're getting according to the logs. I'm not sure what's going on with that.

The period size is the latency you'd like to target. It's not added to any base latency or anything. The way it works is miniaudio will pass the requested latency to the backend, but the backend will be what decides the actual latency that you end up with. So it's essentially just a hint. I highly suspect the reason you can't get lower than 441 is because WASAPI itself is restricting it. If the backend cannot match it exactly, miniaudio will use an intermediary buffer to ensure the data callback is fired with exactly the number of frames you requested in the device config. (You can disable this intermediary buffer with deviceConfig.noFixedSizedCallback = true;, but you won't be guaranteed the callback will be fired with the exact period size you requested in the device config.)

Can you post your full device config here? Also, do you by chance know if you have the same latency issues with non-miniaudio apps that use WASAPI (not ASIO)?

Another experiment you could try to help narrow it down is to see if you get the same latency issue with the DirectSound backend. Not suggesting you switch to DirectSound or anything, just wondering if it might give some additional intelligence as to what's going on. Note that DirectSound has a hard lower limit of 20ms or so (maybe slightly higher).

When I get a chance to boot up my Windows machine I'll take a look on my own hardware just in case I've accidentally introduced a regression somewhere.