On Sat Sep 20 13:21:32 2025 +0000, Huw Davies wrote:
These tests don't seem to test the implemention change.
Well, it does here with the implementation part of the patch reverted: ``` render.c:392: Test failed: InitializeSharedAudioStream returns 88890020 ```
That currently depends on min_period received from get_periods() inside AudioClient3_GetSharedModeEnginePeriod() which depends on the host configured backend periods. Here get_periods() returns 26666 value for min_period, which I suppose a rather common pulseaudio default (no manual changes to pulse config here) and the problem with Malody V was reproduced on different setups as well. That, without the patch, results in 127 samples returned min period (for 48kHz sample rate), and then using that in stream initialization results in the too low value. With the patch it gets rounded up to 128 which reliably avoids the problem. Of course with some different backend / host sample rate the problem might not reproduce, that's why I didn't put the test separately with todo_wine before the fix.
Separately, I am not entirely sure if the current min period is correct, on Windows I see the same values for min and max periods and I don't know how to change that for shared mode stream. But assuming there is some cases when that period is different (maybe might happen on some different hardware on Windows) I guess we do need rounding here: the period in samples depends on sample rate and we probably can't instead be measuring the device periods in samples.