Hi
> > From my experience when it comes to redesigning/rewriting entire
> > project, the "upgrade an already running train" strategy does not work,
> > so I'd not recommend that.
> >
> > Instead, I'd suggest to have a second, separate DPCM implementation
> > present next to the existing one and have users opt in during a so-
> > called deprecation period of the existing one. Once certain amount of
> > time passes, switch all of them. Clean slide also makes it easier for a
> > developer to be creative.
> >
> > Do you view the second option as viable?
>
> Classic problem without a good solution. In practice new features or
> corrections get added to the 'old' framework and the new one is not used
> by anyone just yet so it keeps running behind in terms of
> features/maturity. And due to limited validation resources or limited
> access to a wide variety of hardware, no one is quite ready to enable
> the new framework on 'old' platforms because that would break quite a
> few devices.
>
> The other problem is that the 'switch' would mean a compatible solution,
> but the problem is to get rid of the very notion of front- and
> back-ends. Existing users of DPCM have undocumented hard-coded
> dependencies on the order in which callbacks are handled, it's not easy
> at all to change the routing engine.
I can agree that upgrading existing framework is not good idea.
My Idea is push exising "old" framework as v1, and create new framework as
v2. We can use both version in the same time. And we can add more new
version in the future (if needed).
I think we can use "${LINUX}/sound/soc/generic/test-component.c" to test
v2 framework which is dummy CPU/Codec. Everyone can use and test it without
HW. We already using it as Audio-Graph-Card2 sample.
(${LINUX}/sound/soc/generic/audio-graph-card2-custom-sample.dtsi)
Thank you for your help !!
Best regards
---
Kuninori Morimoto
