[RFC] Dynamic reconfiguration of sampling rate

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

 



On Wed, 2011-01-05 at 11:15 -0600, pl bossart wrote:
> 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,

Thanks for the work - this was something I was hoping to look at at some
point. I tried the patches and they do seem to work fine. Will continue
using them for a bit and see if anything goes awry.

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

In my normal usage, there is a potential (solvable) problem with this
approach, though. I use Rhythmbox and most of my songs are at 44100 Hz,
but there are some at 48000 Hz. If I start playing one of the 48000 Hz
songs, all subsequent streams will be upsampled to 48000 Hz till I pause
for >5 seconds.

As you suggest, this will become less of a problem if we decrease the
idle time required before suspend, and IMO this enough to make this a
non-blocker.

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

Unless I missed something, the only assumption I see in the code is that
one of the sample rates is a 4000 Hz multiple and the other is a 11025
Hz multiple, so using, 88200 Hz with an alternate sample rate of 96000
Hz should also just work.

We could potentially just replace default-sample-rate with
minimum-sample-rate so the sink could be configured to any sample rate
the card supports greater than (say) 44100 Hz. For low-quality streams,
we keep the current logic and upsample to the nearest integer multiple
that is at least minimum-sample-rate.

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

I see the sink being configured correctly for new sink inputs depending
on the sample rate of the stream, but reconfiguration to update the
sample rate of an existing stream on resume doesn't seem to be working.
I'm testing by running Rhythmbox (not using the xfade backend), playing
a 48000 Hz song, switching to a 44100 Hz song, pausing for long enough
to suspend the card and then unpausing. As far as I can tell, the move
callback isn't called on resume.

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