avoid-resampling -> avoid-processing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Fri, 21 Sep 2018, at 6:47 PM, Arun Raghavan wrote:
> On Fri, 21 Sep 2018, at 4:33 PM, Sangchul Lee wrote:
> > > I'm thinking that we should change the avoid resampling flag on sinks to instead be avoid processing -- the idea being that we try not just to reconfigure to a given sample rate, but for the entire sample spec (and eventually channel map as well, once the reconfiguration patches are updated to address Tanu's comments).
> > >
> > > The rationale is that I'd like to avoid having one more aspect of configuration, and the use-case to avoid resampling almost certainly applies to at least bit depth (16 <-> 24, usually) at least, and at that point, why not everything.
> > >
> > > We could provide more fine-grained control (avoid-resampling/-remapping/-conversion/-channel-mix), but I don't see the benefit of this, so I figure a more overarching option is more likely to be useful.
> > 
> > I agree with that. Although the pending patches(sorry to tanu, I'll
> > update soon that with applying your last comments :)) address
> > bit-depth within enabling 'avoid-resampling' option, I also think
> > changing the name to any other one is better than now.
> > (avoid-processing, avoid-resampler, or another one).
> 
> One question -- in avoid-resampling mode, we have a lower bound on the 
> sample rate (as the lowest of default and alternate sample rate). Should 
> we do the same thing for channels, or let the channel count be as low as 
> 1 if the media is so configured?
> 
> I have a mild leaning towards the latter as a sanity check.

Rethinking this, I think we should have a lower-bound defined by the sample-spec as a whole.

-- Arun


[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux