On Tue, Jun 16, 2009 at 4:14 AM, Roderick Colenbranderthunderbird2k@gmail.com wrote:
Hi Arthur,
I would recommend you to also read this thread: http://www.winehq.org/pipermail/wine-devel/2009-June/076102.html
As mentioned before we would like not to have a pulse audio driver if it isn't needed at all. Some suggestions have been made to use some pulseaudio rules of thumb in our winealsa code to improve the situation. This is likely not doable for some of the stuff like mmap which is needed for direct card access (directsound requires that) but fixes in that area could already improve winealsa <-> pulse interaction a lot. Remaining issues might be solvable in cooperation with the pulse developers.
Hi,
Direct card access in my opinion is arguable as to whether it is really needed. I don't think Vista allows you create a hardware buffer anymore. I've written a few wine drivers (gstreamer and pulseaudio native..both gave about the same latency actually) because of the pulseaudio situation and earlier problems with alsa (that maarten largely fixed).
I found you could easily emulate hardware buffers yourself and get most of the benefits of rather then using Wines HEL mode. What this really means that wine's HEL could be improved. There seems to be a lot of latency introduced somewhere inside it since i have always seen a reduction in latency by adding support to create a "hardware" buffer and letting the dsound mixer mix into it rather then letting it do what should be the same work and write out the wavehdrs. Hacking in hardware secondary buffers was where you see the biggest improvement which points to the dsound mixer mixing samples from the secondary buffers to primary as the culprit. But, this can be a hard thing to make fast and not cause audio issues, i've tried and had mixed success with similar tasks.
What I have done is made a simple stream like interface for both my drivers that allows both to use the same stream api to implement the winmm portion and the also use it to provide my own dsound emulation that works best for the driver.
When wine starts to implement XAudio2 (i don't even know if any games require this at this stage) but current i think that would cause another driver like interface which would only make maintaining the drivers very difficult.
I think a lot of issues can already be fixed without requiring a new driver.
I think most probably can be fixed. I think the fallback method might currently have some bugs so when the winealsa driver detects that the pulse emulation can't do what it wants it still does a few things that clash with what pulse provides through alsa.
Anyway...just my view on this issue.
Cheers, Trevor