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

[Colin Guthrie]

'Twas brillig, and pl bossart at 05/01/11 17:15 did gyre and gimble:
> 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.

An excellent way to spend such time!


> 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.

That seems like a sensible limitation. Avoiding the glitches is
obviously got to be top of the list.

> - 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

Yeah, doing it server wide makes no sense IMO. The default-sample-rate
configure option predates our mixer profile logic and really (IMO)
somehow be wrapped up into card profiles or sink/source ports anyway,
but I digress.

> - 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.

While I see the logic behind it, it'll likely not placate all those
people who want dynamic rate switching. Perhaps this will need to be
extended at some point but perhaps it's a sensible starting off point.
I'm thinking more of even larger frequencies rather than lower ones
(although the practical usefulness could obviously be debated endlessly)

> - Some work would be needed to prevent system alerts from
> reconfiguring the sampling rate, but this is a different
> policy-related problem.

Yeah, this could be easily enough done with some kind of proplist entry
implemented in e.g. libcanberra and honoured by PA.

> - 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.

Or perhaps the "OK to change rate" logic could work when the sink is
either IDLE || SUSPENDED ? That way the suspend timeout wouldn't really
matter. Just a thought.

> Please review the code, give it a try and let me know if you think
> this is a useful feature to add.

Not had a chance to review/try the code yet, but I think it's a sensible
feature to add overall.


One thing I think would be very interesting here would be cards that
support hardware mixing.

With these cards, would it be possible to open a stream for each of the
different rates we want to use? Then when we deal with the mixing, we
mix all the like-rated inputs together and send those separately to
their matched device-stream?

That is likely the best use of such hardware and the best implementation
of support for multiple rates, but it's possibly not worth thinking
about immediately due to the fact that this h/w is likely in a minority.

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]