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