Comment 140 for bug 371897
Revision history for this message
|
|
#140 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
a60fb26
(Get the code!)
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.