[PATCH] winepulse.drv: Add PulseAudio driver

[Chris Robinson]

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 */
    ssize_t len;

    pa_threaded_mainloop_lock(data->loop);
    len = pa_stream_writable_size(data->stream) - data->attr.tlength +
          buffer_size;
    pa_threaded_mainloop_unlock(data->loop);

    if(len < 0)
        return 0;
    len -= len%update_size;
    return len;
}

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.