[Bug 10495] Wine should support PulseAudio

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=10495


Art Taylor <theycallhimart at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |theycallhimart at gmail.com




--- Comment #35 from Art Taylor <theycallhimart at gmail.com>  2008-09-24 11:45:13 ---
Hello

This patch adds native support for pulseaudio. It should allow better
performance of over the esound driver. As for problems with performance, the
short answer is, it depends. How are the games seeming to run slow. Personally
I have a pentium-m 1.6 gHz, ATI Radeon 7500 32mb, 1gb ram and I can play Max
Payne 2 without issue (no pixel shaders thought ;-) ), with audio going over
the network or locally.

If the performance slowdown you experience is because of the pulseaudio daemon,
I would check it's configuation (how is it accessing the hardware, what's the
default sample spec vs the sink sample specs, what resampling algorithm is
being used).

On the other hand, if the poor performance is due to windows apps not expecting
a large audio buffer, larger than usual latencies, or that wavehdrs will be
return monotonically rather than in bursts, this patch will help. The patch's
method for returning wavehdrs to the app is based entirely on timing functions
rather than stream position estimates or written totals. This ensures that
audio data appears played at a consistent rate. In fact, if this is your main
problem with audio, this patch will preform better than _any_ of the other
drivers, as really, we are lying to the app here.

A waveout app controls how large it's audio buffer is by how many and how large
of wavehdrs it queues. Apps do not queue more wavehdrs than this size, thus if
no wavehdrs are returned, no new ones will be given. This is a problem if the
size of the app's desired buffer is smaller than pulse's prebuffer, as pulse
will not start playback until the prebuffer is full. If pulse doesn't start
playback, no wavehdr's are returned, no new wavehdr's come in, no new data,
prebuffer will never fill, nothing happens. To deal with this if a stall in the
prebuffer is detected this code will start the wavehdr releasing clock earlier
than when the audio actually starts playing. The upside is apps always work and
seem to get the buffer size they want, the downside is that we are actually
lying to the windows apps, and there really is an extra bit of latency that
they just don't know about. Another upside is that pulseaudio is good at
managing latencies.

WaveIn support in this patch is still hack-ish as I wrote and tested it early
in the morning.


-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.