On Mon, Feb 24, 2020 at 05:59:33PM +0530, Sameer Pujar wrote: > On 2/24/2020 5:14 PM, Mark Brown wrote: > > I don't think so, I'd not expect the individual drivers to be doing > > anything user visible here - if we know what a digital transformation > > looks like the framework should be offering anything that's needed to > > users (and hiding controls that don't have any practical control in a > > given system). > Are you suggesting to have some alternate way of users configuring sample > rates (and other params) and not use mixer control method? I'm mainly saying the driver shouldn't be doing it directly, it should be doing something much closer to hwparams for digital formats. > This is a typical use case we see, > - [stream-1] Lets say high resolution audio is playing (96kHz, 24-bit, > stereo) > - [stream-2] Randomly system notifications of small durations come (48kHz, > 16-bit, stereo) > The requirement is, both streams should be mixed and played. Most systems like this would run the output at a fixed sample rate here so there'd be no runtime configuration. > Is there a better way for user to configure custom audio paths? Fit what you're doing into DPCM. It's not particularly great but it's what we have at the minute. This isn't me not understanding your use case, this is me saying that it would be better to either work like other existing drivers or improve the framework so that it works better for everyone.
Attachment:
signature.asc
Description: PGP signature