Comment 249 for bug 371897

Probably the largest problem for audio in WINE is the WaveOut/WaveIn API's. Currently the WaveOut and WaveIn API's are the base for the other audio api's in WINE (except openAL.) The audio api, designed probably in the early 90s for PCs of the day seems to have been the first implemented in wine, and all audio api's fall-back to it (except openAL and DSound on OSS and ALSA in special occasions.) Probably the biggest pro-native-pulseaudio reason is the waveout functions. Through libalsa pulse, calls such as waveOutReset() and waveOutResume() require a reconnection to pulseaudio each call. Using a native pulseaudio driver we can write audio data into pulseaudio and do the pause, resume and reset calls without penalty.

My two cents is that audio in wine is long overdue for an overhaul. Probably the best way would be to implement some sensible abstracted buffer situation and then have _one_ waveout/wavein driver written to use it. Currently the winmm drivers each contain parallel implementations of the code required to set up another thread to manage feeding the hardware, timing wavehdr's and calling back to the application. Probably the biggest problem with winealsa.drv is that it will exhibit different behavior if it receives different behavior from whatever audio device it is using. The different behavior has to be dealt with by the windows application, which may have it's own issues. The same is probably true of wineoss or others. This is not the native audio api's fault IMO, but the failure of WaveOut/In. In winepulse tried to make it behave the same all the time. The argument that this different behavior is the fault of the alsa driver is also not acceptable. We cannot believe that it is still 1994 and every audio device behaves like we are writing straight to a 10ms DAC buffer.

What is the state of audio in windows these days? I shudder to think that the only way to play audio on a windows box is dsound or waveout. Surely there is a new audio api out of redmond that will require implementing anyways?

In either case, in lue of further progress I'm maintaining a (blasphemous) patch for a native wine pulseaudio backend, and shall continue to maintain it so long as it is useful.