On Fri Jan 23 17:12:29 2026 +0000, Paul Gofman wrote:
We are not free to adjust app-visible state (e. g., we set app's event), that is something which should match Windows behaviour (fwiw, that is not exactly perfect now and that what I am trying to improve in the MR linked above, but in any case we shouldn't be making it to diverse more from Windows). One thing I wouid like to see in the log is how MM device is set up. Specified 'minreq' of 13.3ms is suspicious, minreq is based on mmdevapi 'period' and normally with shared device we should always end up with 10ms period (if pulse setup stipulates more period that setup is essentially broken for us, we can't really work that around and we have to maintain that 10ms to be compatible and avoid issues). Yet I can imagine maybe we can have some problem with those period rounding somewhere and maybe we should be fixing that one. From the existing info I can maybe suspect that minreq which we get from pulse is configured to that mentioned 13.3ms, and in that case lowering it should probably help. In that case there is a question if we want to try to workaround such setups or just suggest to lower it (fwiw I am not sure if there are actual reasons to configure pulse latency that big). If we'd want to workaround that (not exactly sure if we want) I think it can only be correctly done by decoupling app visible buffer draining (the only one which we have now) from actual draining it to pulse. That is, introduce another (bigger) buffer and only copy to that one in the current winepulse loop. Then, have a separate loop which be pushing the data from that backing buffer to pulse and now that loop will be free to adjust timing of those pushes as it is best fit for PA config.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/9840#note_127784