On Fri, Feb 25, 2022 at 03:35:12PM -0600, Pierre-Louis Bossart wrote: > But at a more fundamental level, the main concern I have is with the BE > use: this patchset assumes the BE configuration is fixed, and that's a > very very strong limitation. It's clearly not right for e.g. Bluetooth > offload where multiple profiles need to be supported. It's also not > right when the codec or receiver can adjust to multiple hw_params, which > could lead to simplifications such as removal of unnecessary > SRC/downmixers, etc. > We absolutely want the capability to reconfigure the BE by using > constraint matching between FE hw_params requested by applications and > what the hardware can support. If your solution solved that problem you > would have my full support. But if we're adding a rather complicated > framework on top of a known limitation, then that's really a missed > opportunity to do things better collectively. On the one hand everything you say here is true. On the other hand I *did* suggest starting off with something with stripped down functionality and then building up from that to make things more digestable so some of this could be the result of that approach (I've not got enough recollection of previous serieses to confirm), obviously fixing the output is also quite a common thing for DSP based systems to do just in general.
Attachment:
signature.asc
Description: PGP signature
