Wine sound discussion summary

Roderick Colenbrander thunderbird2k at
Sun Dec 6 13:20:29 CST 2009

On Sun, Dec 6, 2009 at 5:10 PM, Roderick Colenbrander
<thunderbird2k at> wrote:
> On Sun, Dec 6, 2009 at 5:08 PM, Stefan Dösinger <stefandoesinger at> wrote:
>> Am 06.12.2009 um 15:32 schrieb Roderick Colenbrander:
>>> This audio engine is quite similar to
>>> pulseaudio and it offers functionality like per stream volume which
>>> normal APIs like oss/alsa/openal don't offer, so these APIs would map
>>> better to a sound server than to a standard library.
>> I am wondering: Does CoreAudio on OSX offer similar features? Or do we need a sound server there as well if we want to support them?
>> I CC'ed Ken.
>> On the big picture I like the Wine WASAPI proposal. I do however think that we should retain the capability to have multiple backends. Maybe we should go all-in on PulseAudio with its API if that gives us all needed features, and use CoreAudio on OSX if it satisfies our needs without a separate sound server.
>> Stefan
> I just found this document. It is a good summary:
> (expand all bullets)
> Roderick

This is an update for the guys who aren't hanging out on IRC. We still
aren't convinced whether dsound should be layered on top of OpenAL or
WASAPI. An argument for going the OpenAL way would be that DSound3D is
easier and that perhaps the latency is less (I will come back to
latency later). The Vista way is to use MMDevAPI to enumerate
'endpoints' (speakers, headsets, microphones) and then to enable
winmm/dsound/wasapi or whatever you want using MMDevAPI. You are able
to use wasapi calls (IAudio*) with dsound. This allows you to access
the sound buffer, adjust volume, get the position in the stream and so
on. Some of those calls can be mapped to dsound itself (e.g. things to
query the position or frequency) but the fear is that there are things
which are not mappable.

At this point the biggest part of the discussion focuses on WASAPI
itself and how it should be implemented in Wine. We need to start
taking this API into account because in Vista more and more apps rely
on it. For instance World of Warcraft uses WASAPI in Vista and it
doesn't have a fallback to DirectSound. Maarten verified this on Wine
and indeed when you report Vista, you won't receive sound in WoW.
Further XAudio2 and friends also use WASAPI on Vista but I don't know
if those fall back (I guess not).

Regarding on how to implement WASAPI. On Windows there is the 'Audio
Engine' which is quite similar to PulseAudio. We want to avoid
implementing this Audio Engine as it could mean layering our own sound
server on top of another one (pulseaudio) and we are concerned about
performance and overhead. We would like to let the 'audio library' do
all the mixing and hard work. Maarten advocated to use OpenAL as the
audio library. This would allow us to get rid of all the different
audio backends which would make maintenance easier. The others thought
that solely relying on OpenAL would not be wise. The WASAPI makes it
easy to add other tiny backends since a lot of the code can be shared.
The current idea would be to have wine 'audio drivers' implement the
'IAudioEngineEndpoint' interface (see the endpoint blocks in The
design would be made in such a way that multiple backends can be added
with a minimum amount of code. Likely OpenAL would be a reference
backend but we can easily add PulseAudio and CoreAudio.

At the end of the discussion it felt like more and more people lean to
a full WASAPI design. Some fear about latency and mention 'library X'
adds a lot of latency and 'library Y adds even more'. When you
implement your audio subsystem in software you will add more latency
(on XP years ago microsoft accepted max 30ms, yes that's too much for
an FPS). We need proof to justify claims about latency. Chris believes
that pulseaudio contains decent mixing code these days and that the
latency it adds might not be that bad.

Personally I'm in favor of the full WASAPI backend and would have
multiple backends including a Wine pulseaudio one.


More information about the wine-devel mailing list