24.10.2014 01:44, Andrew Eikum wrote: > On Fri, Oct 24, 2014 at 12:38:16AM +0600, Alexander E. Patrakov wrote: >> 24.10.2014 00:08, Andrew Eikum wrote: >>> I have a patch in-hand which improves the current driver >>> significantly, but it isn't enough to fix the USB devices problem. If >>> someone wants to review the winealsa driver with the patch applied and >>> discuss solutions, let me know. I'd love to get this problem solved. >> If you send me the patch, I promise to have a look at it. But, see >> my other reply why there cannot be a full solution within the ALSA >> API. >> > I've attached the patch here. It's been a while since I've worked on > this, so I'm fuzzy on the details. It should apply on any recent Wine > version, including today's. I have looked at the patch, but have not tested it. I cannot say just by reading the code whether this is an improvement. I think that the most important thing here is the removal of the "keep no more than 3 ALSA periods" logic. Still, the patch was useful as it forced me to look at the buffering logic in Wine. > > There's a comment above alsa_write_data() describing how the buffer is > laid out and what the offsets point to. alsa_write_data() is where we > actually send data to ALSA. AudioClient_Stop() and _Start() are where > the stream is rewound and paused. AudioClient_Initialize() is where > the device setup occurs. AudioClock_GetPosition() returns the number > of played frames. > > Note that we explicitly toggle handle_underrun to TRUE in > make_handle_underrun_config(). Toggling this off does seem to have an > impact on USB devices. The underruns aren't fixed in either setting, > but it's worth playing with. As I said, the underruns happen because the pulse plugin provides incorrect information about the actual period size to Wine. > > If I remember correctly, the problem with USB devices is that > snd_pcm_avail_update() updates too infrequently. To keep low latency, > we set up a buffer size of four ALSA periods (about 40ms, I think). > But, snd_pcm_avail_update() updates less frequently than that, so we > constantly hit underruns. Some Windows applications behave very badly > with large latencies. > > I think the issue was more complicated than that, but I've forgotten > the details in the meantime... AFAICS we can confirm or disprove this by logging last_period_time. > > I believe disabling BATCH mode on USB devices "fixes" everything with > this patch applied, but I presume there was a reason it was introduced > in the first place (see PA bug 66962). I could be wrong here, I never > totally understood the issue. That bug is exactly what I am talking about. -- Alexander E. Patrakov
