[PATCH] winepulse.drv: Add PulseAudio driver
chris.kcat at gmail.com
Fri Jun 15 20:23:57 CDT 2012
On Friday, June 15, 2012 3:39:33 PM Andrew Eikum wrote:
> One thing to note is that PulseAudio has an absurdly high default
> latency (two seconds), and due to its poor API there's no (easy) way
> for us to control it.
The latency is likely caused by PulseAudio setting a much larger tlength (and
minreq) than what you asked for. This happens all the time for me when the
server has been running.
The trick I've found to dealing with this in OpenAL Soft is to essentially
ignore what PulseAudio sets and do your free space calculations so that only
the size of the buffer you requested is used. Something like:
size_t writable_size(pulse_data *data)
uint buffer_size = our requested buffer size in bytes;
uint update_size = our expected period size in bytes;
/* This is signed since it could come out negative */
len = pa_stream_writable_size(data->stream) - data->attr.tlength +
if(len < 0)
len -= len%update_size;
The update_size is only relevant if mmdevapi updates in period-sized chunks.
If it doesn't, you can just remove it and the rounding. The tlength should be
kept updated using pa_stream_set_buffer_attr_callback, in case the server
tries to increase it more during runtime.
When creating the stream, I set minreq to the period size, and tlength to the
requested buffer size. I also set the flags PA_STREAM_INTERPOLATE_TIMING,
PA_STREAM_AUTO_TIMING_UPDATE, and PA_STREAM_ADJUST_LATENCY.
The most important part is to not rely on PA_STREAM_EARLY_REQUESTS or the
write callback to tell you when some space is free for writing, since as noted
above, PulseAudio can set unreasonably large values.
This doesn't completely fix the latency problem, as I'll still get better
performance using ALSA's dmix, but it helps immensely.
More information about the wine-devel