Recent activity in http://bugs.winehq.org/show_bug.cgi?id=10495 has caused some issues. This is also a response to http://www.winehq.org/pipermail/wine-devel/2009-April/074666.html
First the background. WinePulse has been an attempt to write a winmm backend for pulseaudio for wine. Currently the primary audio system used by wine is through winmm.dll which sends messages to a backend which basically represents the MS waveOut and waveIn APIs.
WaveOut works through wavehdrs, a single-linked list structure which contains a data field pointing at a buffer. Applications feed wavehdrs via waveOutWrite and receive a message when they have finished being played. wavehdrs can be formed into loops using flags. This is all simple enough except for how variable it is. Applications usually allocate a set size of wavehdrs and then use them circularly. Applications usually use when a wavehdr is returned for timing purposes rather than waveOutGetPosition. The number of wavehdrs and their sizes is entirely up to the application.
There are two common problems with audio drivers implementing this system. The first is drivers which return a wavehdr as soon as it is written to output (waveesd.dr for example) as it will cause timing issues for applications when large batches of wavehdrs are returned at once. The second problem is when a windows application makes a smaller buffer of wavehdrs than the backend provides. In this case wavehdrs are not returned because they have not been played, and no more data can be written to fill the buffer because all the wavehdrs are waiting to be returned from the playback that is stalled. This can happen with alsa on top of plugins. If the buffered wavehdrs and playback buffer are very close in size sometimes the audio stutters by, oscillating to and from underrun and playback.
Winepulse attempts to overcome these problems. It returns wavehdrs accurately and avoids stalls by modifying the pulseaudio server buffer size. In tests it works consistently.
Most of the people I've had contact with have been positive toward development of such a backend. That said, the response from wine developers has been overwhelmingly negative. I can understand the desire for only clean and maintainable code to be considered for submissions. However, often it appears that the rejection is wholly philosophical rather than logical. Continual reports of problems are always contributed to silly users who are not using ALSA on top of direct hardware. I do not dislike either ALSA nor winealsa.drv, but I do reject this skepticism toward a world of Linux audio beyond SB-16 style "direct hardware."
The arguments that PulseAudio adds latency or is not suitable for professional audio are not relevant to the issue of whether or not a pulseaudio backend for wine should be added. The _addition_ of said backend _enables_ audio in wine for those who _choose_ to use pulseaudio. I can't imagine stopping pulseaudio just so I can listen to music through foobar2000, as that would stop all my voice chats, notification sounds, and other native audio, etc. For those whom pulseaudio is not appropriate, the other backends would still exist and pulseaudio can either be disabled temporarily via pasuspender, not started or not installed.
That said, latency in pulseaudio is managed and through the winepulse patch exposed to the windows application. The daemon is usually run with realtime priority and will use data buffers if the requesting application locks temporarily, allowing less worry with recording.
The method of audio playback and capture through waveOut and waveIn are quite broken. Even if winealsa uses the "safe ALSA api subset" it means that the poor and varied behaviours are translated to poor and varied alsa calls (DSound HEL is an exception here.) The winepulse patch attempts to overcome these issues by buffering sanely while trying to keep applications happy in a _consistant_ way.
It is true that currently whitespace is an issue with the patches in the bug report. I will work to resolve this. The file was (supposed to be) indented using 4 spaces as this was the convention in all the other audio backends.
Frankly, calling the code a search and replace from ALSA to PULSE is insulting. If this is true then it is therefore true that winealsa was a search and replace from OSS to ALSA. Almost all the wine audio backends share a common ancestor. The latest patch does not contain comment out code. There has been no *useful assistance* from wine developers (re "No Fucking Way"). As for which parts of the code aren't wine-64 ready, could you please expand?
A detailed, constructive response with a clear vision for where the future of audio in wine lies would be appreciated.
Thanks