[PATCH 0/5] Reconfigure sample rates on resume

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, 2011-03-06 at 16:30 -0600, Pierre-Louis Bossart wrote:
> This is the second version of my endeavors to remove or make SRC
> simpler when possible. An idle non-network, local or passthrough
> devices will be suspended immediately when there aren't any
> inputs. When a new input is connected, we try to resume with the best match
> between requested sample rate and sink sample rate. To make things
> simple, the sink can only support a default and an alternate rate,
> typically 44.1 and 48kHz. Of course the feature is disabled when both
> rates are identical (if the sink cannot be reconfigured).  Tests with
> HDAudio and USB show a negligible added delay but a nice reduction of
> CPU activity.

An alternative idea:

At sink-input trigger a reconfiguration if possible/supported. Sinks
expose a reconfigure_rate method (I'm sure we can find a better name) if
they can do a quick switch.

In the ALSA sink, this function would check if there are no sink-inputs
attached and the rate is supported, and then send a message to the I/O
thread to do the actual reconfiguration. We would cache the rate if
suspended and apply on unsuspend, or do a suspend-reconfigure-unsuspend
if it's running.

With this, we can replace default-sample-rate with a minimum-sample-rate
(anything below this gets upsampled), and use the sink-input sample rate
if supported (or an integer multiple as your code does). The advantage
of course is that we're no longer restricted to two sample rates.

I did a quick walk over the code and this seems feasible. I'm doing
something similar (but far simpler) for passthrough mode in alsa-sink -
when a passthrough input is added, I do the
suspend-update_rate-unsuspend if required and it seems to work fine.

Does this make sense or am I missing something basic here?

Cheers,
Arun




[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux