Sound concerns

Maarten Lankhorst m.b.lankhorst at
Fri Dec 11 16:11:44 CST 2009

Hi Roderick,

Roderick Colenbrander schreef:
>>> If there are any other open concerns, apart from packaging, let me know, since I really want to get dsound openal merged. :)
>>> If there are still concerns that are open I would like to know, especially if they affect wasapi which is defined in include/audioclient.idl and audiopolicy.idl
> One of the things which worries me and which you also mentioned on irc
> is whether openal is the right library to implement wasapi. You
> mentioned that some tasks require a 'server' (for the session guid
> stuff). Further there are other features like per stream volume which
> sound servers support but openal doesn't support this (it would the
> task of a real sound server). I have the feeling that 'classic' sound
> libraries (openal, alsa, oss, ..) are not the right approach for
> implementing a 'sound server'. In my opinion they should be
> implemented on top of CoreAudio/PulseAudio/..
OpenAL supports per stream volume. The service is basically needed if an 
application wants to 'audio groups' all using the same sound card across 
processes, and be able to switch it to some different card with 1 
command. Since I don't think the sessions are persistent, this requires 
a audio service no matter what audio api is used. :)


More information about the wine-devel mailing list