Re: [PATCH] [RFC] ASoC: Conditional PCM support

[Pierre-Louis Bossart <pierre-louis.bossart@xxxxxxxxxxxxxxx>]

On 9/13/24 12:59, Cezary Rojewski wrote:
> On 2024-09-10 10:14 PM, Mark Brown wrote:
>> On Thu, Aug 22, 2024 at 03:57:22PM +0200, Cezary Rojewski wrote:
>>
>>> You've shared many scenarios, I do not think we can cover all of them
>>> here
>>> and while I could agree that current FE/BE (DPCM?) design did not age
>>> well,
>>> we're entering "rewrite how-to-pcm-in-linux" area.
>>> If general opinion is:
>>>     it's too much, we have to rewrite for the framework to scale
>>>     into the next 20 years of audio in Linux
>>
>>> then my thoughts regarding current review are:
>>>     if the avs-driver needs sideband interface, so be it, but do it
>>>     locally rather than polluting entire framework. Switch to the
>>>     framework-solution once its rewritten.
>>
>> On this bit as I mentioned in the prior reply there's been ideas for
>> redesigning how we tackle digital audio which I think there's general
>> agreement would be the best way forwards.  DPCM is very fragile and
>> creaking at the seams, it can't really represent scenarios like the
>> sideband case you've mentioned well.  OTOH a redesign is a very big lift
>> and there's never really a point where it seems constructive to actually
>> block things on it so long as everyone involved is OK with what's going
>> on.
>>
>> The upshot is that while I'd be *really* happy to see investment in the
>> framework side of things I probably wouldn't block a driver specific or
>> DPCM solution simply on the grounds that it's messy.  DPCM would need
>> buy in from other people using DPCM of course, and hopefully at some
>> point someone with one of these issues will find that the cost of
>> maintaining a bodge is going to be enough to push them to do the work
>> (or someone will have free time to just work on the issue).
> 
> 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.