Fate of PulseAudio in WINE

Trevor Davenport trevor.davenport at gmail.com
Tue Jun 16 13:30:42 CDT 2009


On Tue, Jun 16, 2009 at 4:14 AM, Roderick
Colenbrander<thunderbird2k at 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



More information about the wine-devel mailing list