On Sun, Dec 6, 2009 at 5:10 PM, Roderick Colenbrander thunderbird2k@gmail.com wrote:
On Sun, Dec 6, 2009 at 5:08 PM, Stefan Dösinger stefandoesinger@gmx.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: http://support.creative.com/kb/ShowArticle.aspx?sid=25937 (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 http://msdn.microsoft.com/en-us/library/dd316780(VS.85).aspx). 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.
Roderick