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

[Alexander E. Patrakov]

24.10.2014 12:06, David Henningsson wrote:
> On 2014-10-22 18:21, Alexander E. Patrakov 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!
>>
>> A known malware-free test application is Foobar2000 version 1.2. Later
>> versions no longer use DirectSound.
>>
>> This issue is not going to be fixed on the Wine side, because the audio
>> subsystem in Wine is not really maintained, and the maintainer has
>> already privately expressed some negative thoughts about the state of
>> the linux audio ecosystem in general.
>>
>> The correct solution (at least from the "isolate the clients from
>> hardware limitations as thoroughly as possible" viewpoint) would be to
>> consume audio from sink inputs using a timer if the actual sink does not
>> provide sufficiently small minreq. In other words, adapt tsched to BATCH
>> cards and drop non-tsched. But that's a whole project. So, as a stopgap
>> solution for running Wine games on e.g. USB audio (which is a topic that
>> pops up regularly on #pulseaudio IRC channel), let's reduce the default
>> fragment size to a value suitable for unpatched Wine.
>>
>> Regarding the value: on my system, for mp3 playback through Foobar2000,
>> 8ms fragments work, 9ms fragments result in constant underruns.
>>
>> Wine wiki recommends 5ms.
>>
>> On devices that can use tsched, there is no problem.
>
> On Ubuntu, since before my time, this has been the default:
>
> default-fragments = 8
> default-fragment-size-msec = 10
>
> ...so 8 x 10 = 80 ms. If you end up with 5 x 4 = 20 ms, I think that's a
> bit too short/sensitive, we should then increase the number of periods
> to 16 or at least 8 in the same go, so you'll end up with something
> above 50 ms in total. I think this could help against underruns caused
> by inoptimal scheduling.

I have to test this before accepting or rejecting the proposal. Will do 
that later today.

> I discussed this with Alexander briefly on Linuxcon, and I'm not opposed
> to lowering the fragment-size parameter. I have not looked into the wine
> DirectSound driver, but if it requires a period size of 10 ms, why does
> not 10 ms work?

I don't really know, and I now think that the "10 ms fragment" theory is 
not the whole story. In fact, two periods 16 ms each work. I need more 
experiments.

> Also, how well does wine work with non-ALSA sinks, such as bluetooth,
> tunnel sinks, etc?

Bluetooth marginally works (i.e. works acceptably well at small 
distances like 2m, but has some dropouts at 4m) right now, but becomes 
broken if one applies this patch:

http://permalink.gmane.org/gmane.comp.audio.pulseaudio.general/20763

I have not tested tunnel sinks yet.

-- 
Alexander E. Patrakov