[pulseaudio-discuss] [PATCH 0/5] Reconfigure sample rates on resume

[Arun Raghavan]

On Tue, 2011-03-08 at 07:03 -0600, pl bossart wrote:
> > 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.
> 
> So far it's similar to the update_rate() method I added on the sink,
> > 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.
> 
> It's interesting.
> The only problems I see is a potential duplication of code, since you
> force the suspend in the sink, and it's already part of
> module-suspend-on-idle. Meaning you will need to implement this
> message in the BT sink as well. I wonder if there would be potential

I assumed we'd only be implementing this in ALSA for now since we're not
allowing reconfiguration on BT in your patches either. Either way, I
don't expect there to be too much duplication.

> races if the suspend-on-idle timeout happens right after you enable
> the new stream.

This should get serialised in the mainloop as far as I can tell.

> > 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 don't really see a benefit of having more than 2 sample rates. The
> only exception is
> passthrough, where you want to forward the sink-input frequency as is.
> And reading again I think it's the same behavior I implemented?

The benefit is just that if you have ultra-high-quality 88.4/96 kHz
music, it doesn't get resampled. I honestly don't know how many people
out there care about this, but if the hardware supports higher sample
rates, I see no reason to not expose the ability to play that.

> > 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?
> 
> Couldn't you add the same behavior with my patches? If the sink-input
> is passthrough then the desired rate is the sink-input rate.
> Overall I am still not clear on what your alternative implementation
> brings? But I am badly jet-lagged, I may have missed something as
> well.

Yes, whatever the final solution is, I'll definitely be reusing this API
in my passthrough work.

Cheers,
Arun