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
