I’ve just pushed a bunch of patches by Pierre-Louis Bossart that can have a pretty decent CPU/power impact. These introduce the concept of an “alternate sample rate”.
Currently, PulseAudio runs all your devices at a default sample rate, which is set to 44.1 kHz on most systems (this can be configured). All streams running at different sample rates are resampled to this sample rate. Pierre’s patches add an alternate sample rate that we try to switch to under certain circumstances if it means that we can save on resampling cost. This would happen if the stream uses exactly the alternate sample rate, or some integral-or-so multiple of it.
The default value for the alternate sample rate is 48 kHz. So if you’re playing a movie off a DVD where the audio track is typically a 48 kHz stream, and your card supports it, we switch to 48 kHz and avoid resampling altogether. Similarly, while making voice calls, common sample rates are 8, 16, and 32 kHz. These can be resampled to 48 kHz much faster than to 44.1 kHz.
Now for the big caveat — this won’t work if there’s any other stream connected to your sink/source. So if your music player is playing (or even paused) when you get that voip call, we can’t update the rate. This situation can probably be improved by at least allowing corked streams have their sample rate change (so having some random stream connected but not playing — I’m looking at you, Flash! — won’t block rate updates altogether). Hopefully we’ll get this fixed before this feature is released in PulseAudio 2.0.
Thanks to Pierre for all his work on this, and to my company, Collabora, for giving me some time for upstream work!
Adam Williamson
October 18, 2011 — 11:49 am
Not just a good CPU/power impact: this has an audio quality impact too, as resampling always affects audio quality (though some people like the effect of upsampling, some don’t). So thanks!
Arun
October 20, 2011 — 9:13 am
I never did find a perceivable quality difference (though I understand there should be a difference), so I didn’t open that can of worms. :)
Anonymous
October 18, 2011 — 3:18 pm
Can you have multiple alternate sample rates?
Arun
October 20, 2011 — 9:20 am
Short answer — no. Long answer — please see my reply to Mengdong Lin below.
Eric Anholt
October 20, 2011 — 1:19 am
Nice!
I recall that at some point, patches were landing to make PA wake up less for music playback by queuing up longer buffers. I’m still seeing about 33 wakeups/sec from PA and 80ish from rhythmbox while playing music. Is there still hope for that getting better on a default install at some point?
Wang Xingchao
October 20, 2011 — 8:54 am
Eric, did your test include commit: 226ddb1d39f58df638e0a58b8eacd0921071173d? fengguang’s patch can redudes some wakeups. In fact, we tried some solutions to reduce wakeups when playing music, some are raw but takes effect. There’re three fds being polled and the PCM fd for read/write data , the other two for messaging between threads, that’s why alsa-sink could be waked up several times but there’s nothing really for read/write.
–xingchao
Eric Anholt
October 21, 2011 — 11:46 pm
I didn’t pull the tree to do a git describe and check, but I’m on 1.0 so I think I had that commit.
Arun
October 20, 2011 — 9:17 am
Unfortunately, there isn’t a clean solution that can include all use cases and give power savings (right now, it’s crossfades that are blocking us). While it’s possible to push in hacks to make things work, in the long term that’s just going to be harmful to the platform as a whole.
So short answer — for now there isn’t a good way to have these settings by default. It’s something that bothers me as well, but I’ve yet to come up with a good solution (or time for the correct solution, which is a proper filter framework in PulseAudio).
Mengdong Lin
October 20, 2011 — 8:02 am
Nice work! It would be helpful if this method can also handle more than one streams. Eg. if 8, 16, 32, 48 kHz sound are mixed, the device can still switch to 48kHz.
Arun
October 20, 2011 — 9:20 am
This was also my thought when Pierre sent in his first set of patches, but this approach is somewhat vulnerable to badly-behaved clients. If you have a voip stream at, say, 16 kHz that manages to make the first connection and then stays around after your call, all your streams will get downsampled and sound horrible.
So until we rework things to switch sink sample rates on a running stream, this is a necessary compromise.