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
