Hi,
Andrew Eikum argued: -/* buffer size = 10 * 100000 (100 ns) = 0.1 seconds */ +/* buffer size = 100 * 100000 (100 ns) = 1 second */
The tiny buffer size caused audio capture glitches on OSX, where the OS often returns audio in half-second chunks.
That may be good enough for winmm, but that does not solve the problem in general. Since Vista, apps can access mmdevapi directly, thus they won't benefit from this increase in winmm buffer size.
I believe that instead and in general, Wine should decouple WinAPI usage from idiosyncrasies of the underlying OS.
IOW, apps requesting a mmdevapi capture buffer of a size that typically works on native should work in Wine too. If 100-200ms is that typical size, then it must be made to work with Wine's back-ends, perhaps by using a hidden buffer of at least 1s *internally* in winecoreaudio (and presumably winealsa for when Jack is in use). Somehow, Wine must bridge the impedance mismatch between native's 100-200ms buffers and the observed >0.5s buffer requirements on OSX.
BTW, does that imply that input signal processing will see data with 0.5s latency on OSX? Would there be a 0.5s delay in chat applications?
Regards, Jörg Höhle