> 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. Thanks for the feedback. > 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. I wonder what happens if we set the timeout to zero for ALSA devices? > 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. yes. The idea was to keep SRC complexity under control. > 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. That's probably a bug. I didn't try corks/resumes, so it's likely broken. Thanks again for testing! -Pierre
