Somewhat related to this, I am not quite sure I understand why suggestedLatency has any effect on the DirectSound input host buffer size in the first place. Given DirectSound uses circular buffers with cursors, my understanding is that the buffer size has no effect on input latency - PortAudio simply "chases the cursor" and will process input data as soon as the cursor moves, without waiting for the input host buffer to fill up (which it shouldn't anyway, as it would overflow). It seems like suggestedLatency should not be a factor in the input host buffer size calculation; instead, the DS input host buffer size should be a tradeoff between memory usage and likelihood of input buffer overflow.

Looking a bit closer at the code, I think I understand now why the host input buffer size is affected by suggestedLatency: it's because suggestedLatency determines the polling rate (which makes sense), and the buffer needs to be appropriately sized to ensure that it does not overflow between polls.

This does still suggest that allocating a host input buffer that is larger than necessary should be benign (the only downside is increased memory usage), so we might want to impose a clamp on the input buffer size to account for the 31.25ms read cursor granularity.

Hi Etienne,

I really appreciate your engagement with improving PortAudio. However I'm having a hard time digesting this long bug report, it could benefit from more focus.

Does your last comment basically contradict the original report? Maybe you update the original report to reflect your current view.

Would it be possible for you to simplify and clarify the report, perhaps by breaking it up under the following headings:

• brief summary description of problem
• test results demonstrating the problem
• actual identified problem cause (if identified)
• other speculations about the cause of the problem
• [optional] background, history, opinions, etc.

Sure.

Does your last comment basically contradict the original report?

It does not. It only contradicts the quoted section. That was just me thinking out loud about potential fixes. I apologize for the rambling.

brief summary description of problem

I think this is covered by the first part of my report so I'll just repeat it here:

When running paloopback -r48000 -s512 with a DirectSound input device:

• If using --inputLatency 25, the DirectSound host API hangs (as in, the stream callback is never called);
• If using --inputLatency 30, the stream callbacks follow an irregular cadence and glitches are reported;
• If using --inputLatency 35, the stream appears to be fine.

This happens regardless of half duplex or full duplex mode. Output seems unaffected.

test results demonstrating the problem

One way to reproduce is to run paloopback -r48000 -s512 --inputLatency 25 with any DirectSound input device (output doesn't matter). That will produce something like this:

   Default suggested input latency (msec): low = 120.00, high = 240.00
   Default suggested output latency (msec): low = 90.00, high = 180.00
   Running with suggested latency (msec): input = 25.00, out = 240.00
ERROR - stream completion timed out!PortAudio error = Wait timed out
C:\Users\edechamps\Documents\portaudio\qa\loopback\src\audio_analyzer.c:310 - ERROR - startFrame out of bounds
C:\Users\edechamps\Documents\portaudio\qa\loopback\src\audio_analyzer.c:310 - ERROR - startFrame out of bounds
   Amplitudes: left = -1.000000, right = -1.000000
C:\Users\edechamps\Documents\portaudio\qa\loopback\src\audio_analyzer.c:310 - ERROR - startFrame out of bounds
C:\Users\edechamps\Documents\portaudio\qa\loopback\src\audio_analyzer.c:310 - ERROR - startFrame out of bounds
C:\Users\edechamps\Documents\portaudio\qa\loopback\src\paqa.c:1348 - ERROR - No good loopback cable found.
PortAudio QA FAILED! 8908 tests passed, 5 tests failed

C:\Users\edechamps\Documents\portaudio\out\build\x64-Debug\qa\loopback\paloopback.exe (process 30872) exited with code 1.

The "timed out" errors are the cues here - the stream callback never fires. The rest is just paloopback getting confused as a result.

actual identified problem cause (if identified)

DirectSound only provides 31.25 ms read cursor granularity on capture buffers, regardless of the size of the capture buffer, regardless of sample rate, and (seemingly) regardless of hardware or software configuration. This appears to be a bug/limitation in DirectSound itself.

Because of this limitation, if PortAudio allocates a DS capture buffer whose length is less than 31.25 ms, the DS read cursor is stuck at 0 and never makes progress. This in turn means the stream callback never fires.

[optional] background, history, opinions, etc.

The fix I have in mind is to make PortAudio always allocate a capture buffer that is at least 62.50 ms to work around this DirectSound limitation. This should not affect input latency because the size of the capture buffer does not affect latency (PortAudio will consume input data as soon as the read cursor moves regardless). The only downside is slightly increased memory usage for the capture buffer, but that's obviously a better outcome than the stream not working at all.

Thanks.

DirectSound only provides 31.25 ms read cursor granularity on capture buffers, regardless of the size of the capture buffer, regardless of sample rate, and (seemingly) regardless of hardware or software configuration. This appears to be a bug/limitation in DirectSound itself.

Which Windows versions have you tested this on, and/or what is the source of this information, and/or to which Windows versions do you think that this applies to?

Which Windows versions have you tested this on, and/or what is the source of this information, and/or to which Windows versions do you think that this applies to?

My original investigation in dechamps/FlexASIO#29 dates back to 2018, I must have been running on Windows 10 back then. I can still reproduce it today on Windows 11 22H2. I was not the one who noticed it first - it was a bug report from an user of my app. Since then, more users reported this issue to me over time, see e.g. dechamps/FlexASIO#50, dechamps/FlexASIO#110, dechamps/FlexASIO#140. Presumably I would have received even more reports if I hadn't worked around it in my app to avoid small buffer sizes.

Also keep in mind that a DirectSound user faced the exact same problem all the way back in 2011 on Windows 7, citing the exact same read cursor granularity of 31.25 ms.

Given the above, I would basically assume this issue affects all Windows versions starting from Windows 7 at least.

Out of curiosity I ran a few tests to see if there was a similar "minimum granularity" for output DS buffers as well. I was able to observe write cursor granularity of 1.25 ms which is basically good enough for all intents and purposes. So it looks like we only need some kind of fix for the input host buffer, and we can leave the existing output host buffer logic alone.

I have just conducted a preliminary test on my system using AudioMulch (slightly dated version of PortAudio) on Windows 10 with Realtek HD sound on my ASUS motherboard. 48KHz sample rate. PA callback buffer size = 64 frames. I do observe some kind of stalling, however it appears to be different from what's described above.

The test I did was input+output, monitoring input on headphones.

My settings are expressed as follows: "buffer sizes" in frames: 256, 512, 1024, 2048, 4096, 8192, 16384, 32768. These are converted to suggested latency parameters for PortAudio Pa_OpenStream along the lines of:

inputParameters.suggestedLatency = inputBufferSizeFrames / 48000.0;
outputParameters.suggestedLatency = outputBufferSizeFrames / 48000.0;

(of course I support other sample rates, but it's best to use the native rate for this test).

some results are as follows:

input = 256 (i.e. suggestedLatency = 256/48000.0; approx 5.3ms)
output = 256, 512, 1024 => STALL
output = 2048, 4096, 8192, 16384, 32768 => WORKS FINE

output = 2048
input = 256, 512, 1024, 2048, 4096, 8192, 16384, 32768
=> WORKS FINE

output = 256, 512, 1024
input = 256, 512, 1024 => STALL
input= 2048, 4096, 8192, 16384, 32768 => WORKS FINE

So it seems that if the output latency is configured large enough, a small input latency (~5ms) works fine on my system. (Note here that "input latency" is the suggestedLatency passed to Pa_OpenStream not necessarily the DirectSound buffer size.

From this I conclude that the "31.25 ms input read cursor granularity" conjectured above is only present on some systems. The fact that the output latency setting is changing the input latency behavior suggests to me that something else might be going on.

@dechamps do you observe any similar change of behavior if you try different output latencies while keeping the input latency constant?

So it seems that if the output latency is configured large enough, a small input latency (~5ms) works fine on my system.

This is perfectly unsurprising and does not contradict my report. This is because, in full duplex mode, the PortAudio DS code only uses a single buffer size for both input and output, and that buffer size is calculated based on the largest of input and output latency:

Therefore, if you use full duplex mode and a high output latency, what you're doing is hiding the problem.

From this I conclude that the "31.25 ms input read cursor granularity" conjectured above is only present on some systems.

To the contrary - with your experiment you literally reproduced precisely the problem that I originally described!

input = 256, 512, 1024 => STALL
input= 2048, 4096, 8192, 16384, 32768 => WORKS FINE

If you look at CalculateBufferSettings() code, in full duplex mode, for a low enough suggested output latency, a suggested input latency of 1024 frames, 64 frames callback buffer size, your 1024 "STALL" result happens when the calculated host buffer size is ~23 ms, and your 2048 "WORKS FINE" result happens when the calculated buffer size is ~44 ms. This is perfectly consistent with the 31.25 ms read cursor granularity problem from the original report.

I hope that by reproducing the problem yourself you are now convinced that this likely affects most, if not all, systems.