Bug 46297

Hi,

PA's internal 2s buffering breaks many winmm apps in Wine because back when winmm was widely used, the difference between buffer position and speaker position was minimal.  The DAC immediately played what came out of the buffer.

We've been unsuccessful at trying to hint PA that Wine wants small latencies by using a small snd_pcm_hw_params_set_buffer_size, typically near 40ms, with a 10ms period.  Both are granted by PA, yet somehow PA still appears to fill some internal 2s buffer, introducing that much latency.

- When Wine reports true GetPosition information (speaker position) to winmm apps, they get crazy or hang because they are not prepared for buffering 2s of audio data.  Back then, a few hundred ms was largely enough.  A typical app plays ping pong with two 333ms audio buffers.

- When Wine limits the speaker position to not be too far away from written frames, the apps lose their ability to synchronize audio & video.
Yet this is preferable to hanging.

The latter may be acceptable for remote desktop settings, but it's not acceptable for local desktop scenarios just because one element in the audio chain insists on buffering 2s of data.

How can we tell PA or rather the alsa_plugin not to introduce such a huge latency?

Thank you for your help,
      Jörg Höhle