[pulseaudio-discuss] [RFC] Dynamic reconfiguration of sampling rate

pl bossart bossart.nospam at gmail.com
Wed Jan 5 09:15:50 PST 2011

Happy New Year,
During a set of long-haul flights and long waits in airports, I tried
to address one of the recurring concerns listed on this mailing list,
namely the somewhat high CPU usage due to resampling. In most cases
people will listen to music at 44.1kHz. watch movies at 48kHz, or
start a voice call at 8 or 16kHz. Running the sinks/sources at a fixed
default frequency isn't going to be optimal for all cases.
To work-around this limitation, I introduced a new callback for sinks
and sources which can be called to reconfigure the sampling rate. It
works fine on my laptop. However there are a number of limitations on
which I'd like to have comments before moving forward:
- first the change is only possible when the sinks/sources are
suspended. I made this conscious decision to avoid glitches.
PulseAudio runs as a daemon, in most cases the sinks/sources are
suspended when the user want to hear something.
- I decided to have a per-sink/source implementation, and to make the
feature optional. In the case of Bluetooth or other network protocols,
tearing down the link and reconfiguring it may be too long. This
reconfiguration is nearly immediate for a regular ALSA sink
- To avoid quality issues, I limited the sinks to two frequencies,
44.1 or 48kHz. If we allowed for lower sampling rates, it'd be a
problem if additional sink-inputs/source-outputs are created at a
later stage with a higher sampling rate. This means that for a phone
call or voice memo you would still see a resampling, but it should be
lighter with integer instead of fractional ratios.
- Some work would be needed to prevent system alerts from
reconfiguring the sampling rate, but this is a different
policy-related problem.
- the sinks/sources only get suspended after a 5s timeout. This seems
too high for sinks/sources that can be reconfigured quickly. It may
make sense to have different values for the timeout, and make them
dependent on the configuration latency.

Please review the code, give it a try and let me know if you think
this is a useful feature to add.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-core-add-support-for-alternate-sample-rate.patch
Type: application/octet-stream
Size: 12172 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20110105/d91f5f38/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-core-dynamic-change-of-sampling-rate.patch
Type: application/octet-stream
Size: 13366 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20110105/d91f5f38/attachment-0001.obj>

More information about the pulseaudio-discuss mailing list