> 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 races if the suspend-on-idle timeout happens right after you enable the new stream. > 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? > 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. -Pierre
