[Bug 10495] Wine should support PulseAudio

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=10495





--- Comment #144 from Art Taylor <theycallhimart at gmail.com>  2009-09-27 17:05:16 ---
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.

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.