Fate of PulseAudio in WINE
matteo.mystral at gmail.com
Tue Jun 16 15:44:39 CDT 2009
2009/6/16 Trevor Davenport <trevor.davenport at gmail.com>:
> 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:
>> 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.
> 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.
I'm with Trevor on the relative importance of having direct card
access. Windows Vista substantially broke DirectSound, as now
DirectSound can't access the hardware (so it can't use hardware
buffers, hardware mixing, etc.). This means also that any application
written to use DirectSound3D and that pretends to directly access the
hw gets plain 2D stereo sound (and possibly higher latencies as well).
In Vista, MME and DirectSound are emulated on top of the new audio
stack. Here you can find something about these changes, if interested:
Now, I'm not saying that we have to break DirectSound as Microsoft
did, but that emulating hardware access, in some instances (such as
the mmap access to the sound buffers), maybe only when PulseAudio is
present, could be an acceptable solution. I don't think the increased
latencies would be a problem, as, at least from my personal
experience, Windows-DirectSound has quite high latencies (even
pre-Windows Vista, ex. Windows XP).
That said, certainly having someone maintaining "Wine audio
department" would be great.
Just my two cents...
More information about the wine-devel