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

[Alexander E. Patrakov]

23.10.2014 23:27, Arun Raghavan wrote:
> On 23 October 2014 22:46, Alexander E. Patrakov <patrakov at gmail.com> wrote:
>> 22.10.2014 22:21, I wrote:
>>>
>>> Of course, this only applies to ALSA devices that can't use tsched, as
>>> well as to OSS on more exotic platforms.
>>>
>>> This is needed for compatibility with Wine games that use DirectSound8
>>> on distributions such as Arch Linux who don't accept the unofficial
>>> winepulse patch. The reason is that Wine DirectSound8 emulation requests
>>> a period of 10 ms and expects it to work for the purposes of timing. And
>>> in fact, it cannot know (via ALSA API) that it is not going to work!
>>
>>
>> I hereby withdraw the patch, as on IRC I see that Arun said:
>>
>> """
>> I'm not too happy with changing that. It would affect CPU on systems that
>> don't care about Wine.
>> and I really really don't want to work around bad clients in PA. (despite
>> the fact that I am also bitten by this bug)
>> ...
>> Want to start a BrokenClients page?
>> """
>>
>> (note: due to the "cannot know" reason, I still disagree that it is a
>> client-side problem)
>
> I've not looked at the Wine code for this, but I wonder if we can
> guess this by looking at the minreq/tlength values that are returned.

Unpatched Wine just uses ALSA, so, your question is more about the ALSA 
plugin.

Indeed, for native PulseAudio clients, it is possible to use 
pa_stream_get_buffer_attr() once the stream is connected, and winepulse 
patches indeed contain such call. The ALSA plugin does not call this 
function. So, this is indeed part of the problem.

However, even if it did, I think this wouldn't fully help, for two reasons.

1. The plugin has already lied to the application about the permissible 
range of the period sizes. Winepulse uses a test stream to know the 
"correct" buffer metrics.

2. The buffer metrics, if I understand correctly, can change at any time 
due to the stream being moved. There is no way to propagate the change 
to the ALSA application. Winepulse does not reprobe the metrics, either 
(well, it only connects the callback that dumps the changed values to 
the log), so "please reprobe" does not look like a reasonable 
requirement to be imposed on applications.

Due to the need to support dumb wrappers whose APIs do not support 
dynamic buffer metrics, I think that, eventually, PulseAudio will just 
have to support clients (including Wine) with wakeup frequency 
requirements incompatible with those of the sound card.

-- 
Alexander E. Patrakov