[pulseaudio-discuss] [PATCH] Change the default fragment size to 5 ms

[Alexander E. Patrakov]

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