© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
7020100
(Get the code!)
(In reply to comment #195)
> OpenAL is in the git head as far as I know. Windows applications using OpenAL
> are now "first class citizens" if you will, with their buffers going straight
> to hardware if the native libraries support it. There is an open-source DSound
> wrapper on top of OpenAL written in C++ which could be of interest, but I've
> not gotten it to compile yet.
Great, could you point me to the OpenAL driver?
If someone would write the pulseaudio driver patch according to the wine coding standards (where are them?) and complete the missing bits (which functionality is exactly missing/do we need more optimization?) would you accept it in main tree, am I correct?
What is the point of having:
WINE->PULSE->ALSA
instead of
WINE->ALSA-
?
It's pretty clear to me, one less redirection and functions call etc etc...
Again, clearly WINE->ALSA could be better, but as seen as PULSE is basically the de-facto standard (and now -gasp- works) why not support it?
What about OpenAL? would it be like
WINE->OpenAL-
or something else?
Cheers,
Ps. Just to clarify, I have been using wine in the past 3+ years to play WoW.
When in Ubuntu 8.10 (or 8.04 I don't remember exactly), pulseaudio came in, I was losing 30% FPS because bad optimization so I wasn't exactly a fan of it. But now, it seems to work, and because of that I guess it's better to support it straight in wine.