Comment 159 for bug 371897

Sorry if I over reacted, but let me restate why winepulse should be seriously considered:

Reading the comments reveals:

"If someone wants to write a pulseaudio driver, he should feel free to do so,
but he should be aware that just writing a simple 20 line linear PCM out driver
is not sufficient." - Done

Second, this code does _not_ inhibit the possibilities of improving winealsa.drv and alsa-pulse's interactions, or the ability for hard-core gamers to use alsa mmap (with pasuspender.)

Third, this code allows for devices to be selected by the applications. Audio apps can choose which sinks or sources to play or record from the pulse server.

Fourth, code does not require that a new connection to the server and new audio stream be made every call of waveOutReset et a la unlike when we try to use pulseaudio behind the alsa api.

Fifth, it is possible to get audio latency down to 25ms in directsound, maybe less depending on your pulseaudio server. We are talking one memcpy removed from hardware for local audio, and the memcpy happens in the realtime scheduled pulseaudio daemon.

Sixth, wavehdr's are returned to the app based on a timer which is close to actual playback time, causing a more smooth and accurate playback for applications which use when a wavehdr is returned for timing info. This is not the case for wineesd.