http://bugs.winehq.org/show_bug.cgi?id=28723
--- Comment #46 from Alexey Loukianov mooroon2@mail.ru 2011-11-11 21:53:28 CST --- (In reply to comment #45)
When you pump out data at fixed intervals...
Thanks for explaining, your points seems to make really big sense.
Yet I think that a heuristic like "if near underrun, feed ALSA a little" may be ok, nevertheless one must carefully assess how this affects..
Yeah, but then IMO it would be more important to get xrun-free behavior at first, regardless it would result in slightly bigger latency, and then proceed with adding heuristics trying to shrink latency carefully testing each and every optimizing change in code.
(In reply to comment #44)
Sorry for the short comment -- what I've been missing from the patches so far is a path for apps that don't care about short periods and buffers, e.g. winmm:playsound. I.e. when an app calls mmdevapi with a large duration, ALSA should not be used with a 5ms period, e.g. 200 timer interrupts per second.
Good point, but it would diverse winealsa.drv mmdev behavior from what is observed on native OS. My tests seems to show that from client POV Win7 mixer always "ticks" in 10ms, no matter the buffer size client requests. Having Wine behaving in some other way might be perfectly OK for some cases but would cause problems with poorly written apps that rely on this undocumented behavior. For this optimization to work we need some other criteria except for buffer size to proceed with long periods. Maybe best bet would be to make a judgment basing on presence of event: we may assume that in case app wants to receive events - it wants to minimize latency using event-driven shared mode buffer fills and react accordingly. Real apps tests would be needed to prove if this assumption is wrong or not.
Also, take a look into MSDN. There it is explicitly stated that for the shared mode non-event-driven render stream the latency is only dependent on the difference between the position where an app writes data to the buffer and the position an audio engine reads data from the buffer. It leaves us with a tiny period requirement no matter the buffer size :-(.
- GetPosition seems 30-40ms away from padding position in shared mode, but
extremely close to padding in exclusive mode. I'm unsure how to explain that.
Well, as (A) in the best case (from latency POV) the buffer for exclusive mode is a real buffer HW DMA engine is reading from, and (B) there's no mixer-in-the-middle - having padding to be extremely close to GetPosition is pretty reasonable IMO for exclusive mode. You simply don't have latency-introducing entities downstream from app to the sound hardware so there's no reasons for padding to differ heavily from real playback position. I assume that you're writing about non-event driven exclusive mode, as the value of GetCurrentPadding is meaningless for event-driven exclusive mode.
BTW, about GetPosition, did you use my patch from comment #32 or something else?
No, I hadn't tried to fixed Wine's GetPosition up till yesterday and had tried to quickly hack-in my own implementation afterwards. My implementation is pretty bogus ATM, thanks for reminding me about the existence of your WIP patch targeting this problem.