ASoC: soc-pcm2.c ?

ASoC: soc-pcm2.c ?

[Kuninori Morimoto]

Hi ASoC ML

I have been cleanuping ASoC framework.
I have started it after seeing Lars-Peter's presentation at ELC-E (almost
15 years ago ?). It was for updating ASoC framework.
I have very agrred his idea, but I worried that it will be very difficult.
Because in my opinion, controlling complex HW by complex SW is inpossible,
and ASoC framwork was very complex. So I started to cleanup framework to
help him.

I want to keep cleanuping, but one of the file which I can't cleanup is
soc-pcm.c, especially around DPCM. I know how to use it, but I still can't
undersand how it is working. I have talked it with Mark at OSS-Japan last
year, and he had same/similar opinion.

For me, current DPCM looks like forcefully expanded functionality.
I think support modern Sound HW on current DPCM is not impossible, but
unique implementation is required on each vendor driver side.

I think keeping cleanup/update current soc-pcm.c, and makes it more modern
style is impossible or very difficult, and/or it may become irreversible code
in worst case.

So may I suggest to create new soc-pcm2.c, like below ?

(A)	  soc-pcm.c
(B)	+ soc-pcm2.c
	  ...
	  audio-graph-card2.c
(C)	+ audio-graph-card3.c

All existing drivers uses existing soc-pcm.c (A). Nothing changed.
And create new soc-pcm2.c (B) and new card driver, for example
audio-graph-card3.c (C).
audio-graph-card3 (C) user only can access to soc-pcm2 (B).

In this case, existing user will get zero damage from new soc-pcm2.c (B).
We can just remove (B) and (C) file in worst case, it is easy to rollback.
But what do you think ?

In my understanding, current DPCM searches path and power via DAPM in
runtime. Because of it, the code become very complex. We would like to have
more simple style in soc-pcm2.

OTOH, we need to call amixer to use Codec, like this

	> amixer set "Mixin PGA" on
	> amixer set "Mixin PGA" 50%
	> amixer set "ADC" on
	> amixer set "ADC" 80%
	> amixer set "Aux" on
	> amixer set "Aux" 80%
	> amixer set "Mixin Left Aux Left" on
	> amixer set "Mixin Right Aux Right" on
	> amixer set "Mic 1" on
	> amixer set "Mic 1" 80%
	> amixer set "Mixin Left Mic 1" on
	> amixer set "Mixin Right Mic 1" on

This means, user need to understand Codec circuit and/or board schematic.
Even if the path setting was correct, we can't get basinc sound without
each volume settings, because default value is zero settings. We need to
setup both "path" and "volumes" to use Codec.

But it is not realistic premise IMO. I don't think *all* user understand
it by themself. I think user don't need to care detail of HW. It should be
handled by Kernel (= Kernel developer), not user, at least basic path and
volume settings.
At least, default path and default volume should be set by default without
any settings from user, I think.

So I want to reduce amixer use case as much as possible somehow.
Not zero, but volume control or some kind of feature
(= for example "noise cancel") ON/OFF only, etc.


I'm now thinking for soc-pcm2 is that we can use "graph" and "routing" ?
Here "graph" means, physical HW connections, like below

	+---- CPU ----------+    +----- Codec -------+
	|                   |    |                   |
    -->	| [A]--+-[C]-+--[D] | -- | [a]--+-[b]-+--[c] | ->
    -->	| [B]-/             |    |             \-[d] | ->
	+-------------------+    +-------------------+

This is very simple graph image.
[C] is Mixer
[b] is selector
Others are some kind of features.

And "routing" is for example

	1: [A]-[C]-[D]-[a]-[b]-[c]
	2: [A]-[C]-[D]-[a]-[b]-[d]
	3: [B]-[C]-[D]-[a]-[b]-[c]
	4: [B]-[C]-[D]-[a]-[b]-[d]

In Codec, each [x] connections are handled by DAPM, in my understanding,
but we don't have such code for CPU side today.
I think DAPM is for "Power Management", but is same as "routing".
I think we can expand it or create similar system for CPU too ?

Anyway, both "graph" and "routing" are fixed, not changed after boot.
No need to search path in runtime in this idea. So no need to call amixer
(for path setting. It wil be setup from inside kernel, etc).
Above "graph" is good match to modern Sound HW ?

In this case, device number = path, like this

	> aplay -D hw:0,1 // path 1:
	> aplay -D hw:0,2 // path 2:
	...

It will just fail if some path can't work in the same time,
for example above 1 vs 2.
Good point is that no runtime search is needed (= can be simple code),
Bad point is that number of "routing" can be explosion, but it is very
rare cases ?


Sound HW/system is very complex, and ASoC allows .trigger and .hw_param
etc in the same time. So we need to have many locks (for each modules, for
routing, etc). Because of this, current ASoC has tons of locks, and need
complex lockdep ?

I know this is not so good idea, but how about to have only one lock, like
"graph lock" ? This is just opinion, but having one large lock is not so
good idea, but better than very complex and un-controllable code.
I don't think .trigger and .hw_param are called frequently in the same time...
Yes, maybe realtime side can be problem though...

I think we can use existing Codec driver as-is in soc-pcm2, but, CPU driver
needs to be re-maked (?), especially DPCM user. But not sure...

If I create soc-pcm2.c, I will create sample CPU driver and its sample DTSI
file, like ${LINUX}/sound/sbboc/generic/audio-graph-card2-custom-sample1.dtsi.
People can easily try/test it by just including it in your DTSI file.
No HW / no implementation is needed for testing. And I think it can be good
sample code to create new CPU driver ?

I have indicated many random topics, but these are just my idea.
My motivation is I want to cleanup ASoC framework, but can't on soc-pcm,
especially around DPCM. There is no guarantee I can create soc-pcm2, but
have interesting. But what do you think ?

Thank you for your help !!

Best regards
---
Kuninori Morimoto

Re: ASoC: soc-pcm2.c ?

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 7988 bytes --]

On Mon, Jan 26, 2026 at 06:41:50AM +0000, Kuninori Morimoto wrote:

> I think keeping cleanup/update current soc-pcm.c, and makes it more modern
> style is impossible or very difficult, and/or it may become irreversible code
> in worst case.

> So may I suggest to create new soc-pcm2.c, like below ?

> (A)	  soc-pcm.c
> (B)	+ soc-pcm2.c
> 	  ...
> 	  audio-graph-card2.c
> (C)	+ audio-graph-card3.c

> All existing drivers uses existing soc-pcm.c (A). Nothing changed.
> And create new soc-pcm2.c (B) and new card driver, for example
> audio-graph-card3.c (C).
> audio-graph-card3 (C) user only can access to soc-pcm2 (B).

> In this case, existing user will get zero damage from new soc-pcm2.c (B).
> We can just remove (B) and (C) file in worst case, it is easy to rollback.
> But what do you think ?

So, as we disucssed in person on the one hand this is obviously not an
ideal way of doing things but I think in this case there's so much
fragility with the current code that it's difficult to do anything
safely which makes this much more viable.  It minimises disruption to
users of the existing code so we get much less stress all round,
hopefully in the long term people will convert to this code and we can
retire the old things.

> In my understanding, current DPCM searches path and power via DAPM in
> runtime. Because of it, the code become very complex. We would like to have
> more simple style in soc-pcm2.

Well, the big issue is that it's sort of partially using DAPM but DAPM
doesn't have full awareness of the system including none of things like
SRC.

> This means, user need to understand Codec circuit and/or board schematic.
> Even if the path setting was correct, we can't get basinc sound without
> each volume settings, because default value is zero settings. We need to
> setup both "path" and "volumes" to use Codec.

> But it is not realistic premise IMO. I don't think *all* user understand
> it by themself. I think user don't need to care detail of HW. It should be
> handled by Kernel (= Kernel developer), not user, at least basic path and
> volume settings.

> At least, default path and default volume should be set by default without
> any settings from user, I think.

I'm not sure I'd go that far.  The trouble with setting a default path
and volume is working out what a suitable setting is for a given piece
of hardware - the really common case where this is a problem is that
many headphone drivers can also be line outputs but the volume levels
needed for the two are vastly different.  That's why we currently just
go with hardware defaults for everything, it avoids trying to code in
settings for a specific system.  It's clearly not ideally helpful for
users but it's a lot easier for them to fix problems with UCM than it is
for them to fix problems using the kernel.

But that said once the code has a better understanding of how things are
wired up prehaps we can have some algorithm that can try to guess a good
default, possibly something people enable optionally.

> So I want to reduce amixer use case as much as possible somehow.
> Not zero, but volume control or some kind of feature
> (= for example "noise cancel") ON/OFF only, etc.

You also get fancier systems where the users really want to fine tune
everything, mobile phones are often an example of this - everything is
very closely tuned for the platform.  The end user never sees this
control, they just get a volume usually, but the people dealing with
ALSA do.  One of the issues we have is that we're catering for both end
users who just got a laptop and want to use it with a generic distro and
system integrators who are building something where the user is only
ever going to interact with a custom software stack that the system
integrator has fine tuned.

> In Codec, each [x] connections are handled by DAPM, in my understanding,
> but we don't have such code for CPU side today.
> I think DAPM is for "Power Management", but is same as "routing".
> I think we can expand it or create similar system for CPU too ?

Yes, that would be ideal.  The power<->routing thing in the name is that
we're trying to minimise power usage by only powering up the things that
are needed for the currently active audio paths so we use the routing to
figure out what needs powering up.  It uses the routing to control power.

> Anyway, both "graph" and "routing" are fixed, not changed after boot.
> No need to search path in runtime in this idea. So no need to call amixer
> (for path setting. It wil be setup from inside kernel, etc).
> Above "graph" is good match to modern Sound HW ?

The graph is generally fixed, where there's anything changing it's
usually just something being plugged into a port, but there's systems
where the routing can be more dynamic.  For a really simple example a
tablet might flip left and right speakers depending on which way up it's
being held.  You could do that in software with a DSP but you could also
do it through routing in the hardware (and depending on how the DSP
looks it might look more like hardware to the host computer...).  You
also get things like routing around some effects blocks depending on use
case, just turning the effect on or off might mean the effect is still
causing latency so instead it's disabled by not routing the audio to the
IP at all.

My impression is that the systems that need to do dynamic routing beyond
just turning on and off some paths are getting less common but they do
still exist, and older hardware tends to stick around for a long time at
lower price points (eg, you'll see what was once a cutting edge CODEC on
a board with a low end SoC because these days the packaging it uses is
much more easy to assemble).

> Bad point is that number of "routing" can be explosion, but it is very
> rare cases ?

It's definitely rarer that people want to be really flexible at runtime,
but it is a thing that happens.

> I know this is not so good idea, but how about to have only one lock, like
> "graph lock" ? This is just opinion, but having one large lock is not so
> good idea, but better than very complex and un-controllable code.
> I don't think .trigger and .hw_param are called frequently in the same time...
> Yes, maybe realtime side can be problem though...

I think that's a good place to start TBH - it's pretty much what we have
for DAPM with the DAPM lock.  We can always go back and rework things to
make the locking finer grained but hopefully that's not needed, we just
don't need to do things that take the lock for long enough or often
enough that people get worried about contention.

> I think we can use existing Codec driver as-is in soc-pcm2, but, CPU driver
> needs to be re-maked (?), especially DPCM user. But not sure...

I'd definitely expect way more impact on CPU side - ideally the CODECs
would be unchanged, but if we need some updates it's not the end of the
world.

> If I create soc-pcm2.c, I will create sample CPU driver and its sample DTSI
> file, like ${LINUX}/sound/sbboc/generic/audio-graph-card2-custom-sample1.dtsi.
> People can easily try/test it by just including it in your DTSI file.
> No HW / no implementation is needed for testing. And I think it can be good
> sample code to create new CPU driver ?

Yes, being able to work on this without needing some specific hardware
would be great - it's one of the big drawbacks with DPCM and one of the
things that make it fragile.  If we can get a good development and
testing setup that allows people to do work without needing to worry so
much about what other hardware will be impacted that would be a massive
win.

> I have indicated many random topics, but these are just my idea.
> My motivation is I want to cleanup ASoC framework, but can't on soc-pcm,
> especially around DPCM. There is no guarantee I can create soc-pcm2, but
> have interesting. But what do you think ?

I'm super greatful that you want to spend time tackling these things,
I think this is heading in roughly the right direction.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: ASoC: soc-pcm2.c ?

[Kuninori Morimoto]

Hi Mark

> > (A)	  soc-pcm.c
> > (B)	+ soc-pcm2.c
> > 	  ...
> > 	  audio-graph-card2.c
> > (C)	+ audio-graph-card3.c
> 
> > All existing drivers uses existing soc-pcm.c (A). Nothing changed.
> > And create new soc-pcm2.c (B) and new card driver, for example
> > audio-graph-card3.c (C).
> > audio-graph-card3 (C) user only can access to soc-pcm2 (B).
> 
> > In this case, existing user will get zero damage from new soc-pcm2.c (B).
> > We can just remove (B) and (C) file in worst case, it is easy to rollback.
> > But what do you think ?
> 
> So, as we disucssed in person on the one hand this is obviously not an
> ideal way of doing things but I think in this case there's so much
> fragility with the current code that it's difficult to do anything
> safely which makes this much more viable.  It minimises disruption to
> users of the existing code so we get much less stress all round,
> hopefully in the long term people will convert to this code and we can
> retire the old things.

Thanks.
Yes, (B) should not have any effect to existing (A) envailonment, should
keep independent from it. If this premise is maintained, we can do anything
on new soc-pcm2 (B).

> Well, the big issue is that it's sort of partially using DAPM but DAPM
> doesn't have full awareness of the system including none of things like
> SRC.

So we want to expand it or create new one.
DAPM is using "string match" method to check path/routing, but I want to
use pointer style for it.

> I'm not sure I'd go that far.  The trouble with setting a default path
> and volume is working out what a suitable setting is for a given piece
> of hardware - the really common case where this is a problem is that
> many headphone drivers can also be line outputs but the volume levels
> needed for the two are vastly different.  That's why we currently just
> go with hardware defaults for everything, it avoids trying to code in
> settings for a specific system.  It's clearly not ideally helpful for
> users but it's a lot easier for them to fix problems with UCM than it is
> for them to fix problems using the kernel.
> 
> But that said once the code has a better understanding of how things are
> wired up prehaps we can have some algorithm that can try to guess a good
> default, possibly something people enable optionally.

OK. I think default routing / volume is set by Card instead of CPU/Codec,
because it depends on Board, not chip.

I have mentioned that I want to reduce amixer settings, but it doesn't
mean soc-pcm2 doesn't allow to use it.

Whether having default volume or not should not mandatory, should be just
option. We want to have flexible framework, like some board want to use same
style as before (= setup full routing etc via amixer), and/or some board want
to have default routing/volumes, etc.


> The graph is generally fixed, where there's anything changing it's
> usually just something being plugged into a port, but there's systems
> where the routing can be more dynamic.  For a really simple example a
> tablet might flip left and right speakers depending on which way up it's
> being held.  You could do that in software with a DSP but you could also
> do it through routing in the hardware (and depending on how the DSP
> looks it might look more like hardware to the host computer...).  You
> also get things like routing around some effects blocks depending on use
> case, just turning the effect on or off might mean the effect is still
> causing latency so instead it's disabled by not routing the audio to the
> IP at all.
> 
> My impression is that the systems that need to do dynamic routing beyond
> just turning on and off some paths are getting less common but they do
> still exist, and older hardware tends to stick around for a long time at
> lower price points (eg, you'll see what was once a cutting edge CODEC on
> a board with a low end SoC because these days the packaging it uses is
> much more easy to assemble).

Ah, OK
It should allow that graph itself can be updated runtime.
And, I think amixer still can work for dynamic routing ?
These can be good example for test case, I think.

> I think that's a good place to start TBH - it's pretty much what we have
> for DAPM with the DAPM lock.  We can always go back and rework things to
> make the locking finer grained but hopefully that's not needed, we just
> don't need to do things that take the lock for long enough or often
> enough that people get worried about contention.

Thanks.
Let's start with big lock, first.

> Yes, being able to work on this without needing some specific hardware
> would be great - it's one of the big drawbacks with DPCM and one of the
> things that make it fragile.  If we can get a good development and
> testing setup that allows people to do work without needing to worry so
> much about what other hardware will be impacted that would be a massive
> win.

Nice to know

> > I have indicated many random topics, but these are just my idea.
> > My motivation is I want to cleanup ASoC framework, but can't on soc-pcm,
> > especially around DPCM. There is no guarantee I can create soc-pcm2, but
> > have interesting. But what do you think ?
> 
> I'm super greatful that you want to spend time tackling these things,
> I think this is heading in roughly the right direction.

I'm busy for a while, but want to do this this year.
I can enjoy this :)

I think the initial design is very important for soc-pcm2.
So I will not care about detail things first (= sampling rate, channels,
etc,...), but focus about graph / routing thinks. I think this is the
main part for it.

Thank you for your help !!

Best regards
---
Kuninori Morimoto

Re: ASoC: soc-pcm2.c ?

[Pierre-Louis Bossart]

On 2/3/26 07:27, Kuninori Morimoto wrote:
> So I will not care about detail things first (= sampling rate, channels,
> etc,...), but focus about graph / routing thinks. I think this is the
> main part for it.

If we truly want to support digital routing, then this information is very much needed.

The graph may include elements that are required to adjust between 'domains' or skipped.
For example if your ALSA PCM device is configured for 8kHz and your codec DAI only supports 48kHz an SRC-based path needs to be enabled. Conversely if the ALSA PCM device and codec DAI both operate at 48kHz then the SRC can be skipped completely and not even be represented in the graph.

In addition, even if the sampling rate/ch/resolution properties are added to the graph, the concept of propagating information to downstream processing may not fly in all cases. For example, a mixer will typically be configured at a fixed frequency. The mixer should not be reconfigured dynamically to account for changes in the streams that need to be mixed, it's these streams that need to be adjusted prior to mixing.

I personally really liked Lars' notion of 'domain' to define strict/well-defined boundaries connecting subgraphs.

Re: ASoC: soc-pcm2.c ?

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1040 bytes --]

On Tue, Feb 03, 2026 at 02:34:36PM +0100, Pierre-Louis Bossart wrote:
> On 2/3/26 07:27, Kuninori Morimoto wrote:
> > So I will not care about detail things first (= sampling rate, channels,
> > etc,...), but focus about graph / routing thinks. I think this is the
> > main part for it.

> If we truly want to support digital routing, then this information is
> very much needed.

Right, it'll be needed for production use.  I do think it might be
viable to work out the managing the connections and then go back later
and propagate the parameters, that's how I understand the above.

> I personally really liked Lars' notion of 'domain' to define
> strict/well-defined boundaries connecting subgraphs.

Me too - I'd come up with something that was extremely similar at about
the same time, IIRC there were some small differences round the edges
but nothing major.

Please fix your mail client to word wrap within paragraphs at something
substantially less than 80 columns.  Doing this makes your messages much
easier to read and reply to.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: ASoC: soc-pcm2.c ?

[Kuninori Morimoto]

Hi Mark, Pierre-Louis

Thank you for your feedback

> > > So I will not care about detail things first (= sampling rate, channels,
> > > etc,...), but focus about graph / routing thinks. I think this is the
> > > main part for it.
> 
> > If we truly want to support digital routing, then this information is
> > very much needed.
> 
> Right, it'll be needed for production use.  I do think it might be
> viable to work out the managing the connections and then go back later
> and propagate the parameters, that's how I understand the above.

Because creating pcm2 needs very long way I think, we can't get very perfect
product level pcm2 in 1st patch.
So 1st step is very basic graph / routing things, and it can do nothing.
In this step, graph is not complex, and routing is manual.

Eventhough it is very simple graph/routing, I guess many opinion / discussion
etc will be happen, and many back and forth will be happen.

Of course I will care about for example SRC thing you mentioned in 1st step,
but its discussion will be started at 2nd or later steps, I guess.

> > I personally really liked Lars' notion of 'domain' to define
> > strict/well-defined boundaries connecting subgraphs.
> 
> Me too - I'd come up with something that was extremely similar at about
> the same time, IIRC there were some small differences round the edges
> but nothing major.

I think I don't know about this.
Could you please indicate me where I can know, or can you explain to me ?

Thank you for your help !!

Best regards
---
Kuninori Morimoto

Re: ASoC: soc-pcm2.c ?

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 552 bytes --]

On Wed, Feb 04, 2026 at 06:19:58AM +0000, Kuninori Morimoto wrote:
> Hi Mark, Pierre-Louis

> > Me too - I'd come up with something that was extremely similar at about
> > the same time, IIRC there were some small differences round the edges
> > but nothing major.

> I think I don't know about this.
> Could you please indicate me where I can know, or can you explain to me ?

I don't think there's anything easily referencable - once I saw Lars'
stuff I didn't feel any need to write it up properly or anything since
it was basically the same thing.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: ASoC: soc-pcm2.c ?

[Liam Girdwood]

On 2/3/26 06:27, Kuninori Morimoto wrote:
> 
> Hi Mark
> 
>>> (A)	  soc-pcm.c
>>> (B)	+ soc-pcm2.c
>>> 	  ...
>>> 	  audio-graph-card2.c
>>> (C)	+ audio-graph-card3.c
>>
>>> All existing drivers uses existing soc-pcm.c (A). Nothing changed.
>>> And create new soc-pcm2.c (B) and new card driver, for example
>>> audio-graph-card3.c (C).
>>> audio-graph-card3 (C) user only can access to soc-pcm2 (B).
>>
>>> In this case, existing user will get zero damage from new soc-pcm2.c (B).
>>> We can just remove (B) and (C) file in worst case, it is easy to rollback.
>>> But what do you think ?
>>
>> So, as we disucssed in person on the one hand this is obviously not an
>> ideal way of doing things but I think in this case there's so much
>> fragility with the current code that it's difficult to do anything
>> safely which makes this much more viable.  It minimises disruption to
>> users of the existing code so we get much less stress all round,
>> hopefully in the long term people will convert to this code and we can
>> retire the old things.

Morimoto-san, first of all I think its really good you are taking time 
to improve things, however there are still some things we need to watch 
in order to make sure we maintain functionality and align with the audio 
integration ownership differences (i.e. who does what) between Linux and 
Windows on the client when Linux is installed afterwards.

Btw, I'm assuming pcm2 will reuse existing DAI and codec drivers but 
without the DAPM/DPCM flows ? i.e. same codec/dai binaries shipped by 
distros can be used by both pcm and pcm2 ?

> 
> Thanks.
> Yes, (B) should not have any effect to existing (A) envailonment, should
> keep independent from it. If this premise is maintained, we can do anything
> on new soc-pcm2 (B).
> 
>> Well, the big issue is that it's sort of partially using DAPM but DAPM
>> doesn't have full awareness of the system including none of things like
>> SRC.
> 
> So we want to expand it or create new one.
> DAPM is using "string match" method to check path/routing, but I want to
> use pointer style for it.

It should hopefully be easy to convert to an integer/pointer format here 
with some search/replace, however the mux enum controls reuse the 
strings in the kcontrol names IIRC so you may need to keep those.

> 
>> I'm not sure I'd go that far.  The trouble with setting a default path
>> and volume is working out what a suitable setting is for a given piece
>> of hardware - the really common case where this is a problem is that
>> many headphone drivers can also be line outputs but the volume levels
>> needed for the two are vastly different.  That's why we currently just
>> go with hardware defaults for everything, it avoids trying to code in
>> settings for a specific system.  It's clearly not ideally helpful for
>> users but it's a lot easier for them to fix problems with UCM than it is
>> for them to fix problems using the kernel.
>>
>> But that said once the code has a better understanding of how things are
>> wired up prehaps we can have some algorithm that can try to guess a good
>> default, possibly something people enable optionally.
> 
> OK. I think default routing / volume is set by Card instead of CPU/Codec,
> because it depends on Board, not chip.
> 
> I have mentioned that I want to reduce amixer settings, but it doesn't
> mean soc-pcm2 doesn't allow to use it.
> 
> Whether having default volume or not should not mandatory, should be just
> option. We want to have flexible framework, like some board want to use same
> style as before (= setup full routing etc via amixer), and/or some board want
> to have default routing/volumes, etc.

I think hiding any kcontrols or hard coding kcontrols that change audio 
processing or routing will break all client use cases, yes this may be 
nice on IoT where there is no sound server or userspace audio infra and 
very simple audio is needed, but on client we need the soundserver e.g. 
Pipewire, CRAS or audio HAL to configure and control the use case/policy.

Its also far simpler for regular users to work with changes in userspace 
whether that be Pipewire configuration, UCM, Audio HAL config compared 
to making similar audio configuration changes hard coded in the kernel.

The other thing to consider is that the integration model for audio is 
fully done by the OEM when you buy a device with an OS pre-installed 
i.e. if you buy a laptop with Linux or Windows then the OEM will fully 
integrate the audio driver including DSPs, DAIs, DMAs, codecs, amps, 
jacks alongside any userspace configuration like topology and UCM.

When a user buys a laptop with Windows then installs Linux there is no 
integration done by the OEM. The user has to rely on the existing kernel 
audio drivers for DSP, codec, DAIs, DMA, amps, etc to probe() and take a 
reasonable guess at the integration configuration. Sadly, the hardware 
schematics required to perform the full audio integration are not 
public, yes the codec/dsp/dma/dai is known but its not known how they 
are all connected to each other and to board specific amps/jacks, and 
hence the alsamixer and kernel quirks methods are often the simplest way 
to enable such devices instead of a new machine driver to manage the 
kcontrols and config (as I think you may have been proposing?). I 
appreciate this is not perfect, but without HW schematics we are in a 
difficult position to begin with.

> 
> 
>> The graph is generally fixed, where there's anything changing it's
>> usually just something being plugged into a port, but there's systems
>> where the routing can be more dynamic.  For a really simple example a
>> tablet might flip left and right speakers depending on which way up it's
>> being held.  You could do that in software with a DSP but you could also
>> do it through routing in the hardware (and depending on how the DSP
>> looks it might look more like hardware to the host computer...).  You
>> also get things like routing around some effects blocks depending on use
>> case, just turning the effect on or off might mean the effect is still
>> causing latency so instead it's disabled by not routing the audio to the
>> IP at all.
>>
>> My impression is that the systems that need to do dynamic routing beyond
>> just turning on and off some paths are getting less common but they do
>> still exist, and older hardware tends to stick around for a long time at
>> lower price points (eg, you'll see what was once a cutting edge CODEC on
>> a board with a low end SoC because these days the packaging it uses is
>> much more easy to assemble).
> 
> Ah, OK
> It should allow that graph itself can be updated runtime.
> And, I think amixer still can work for dynamic routing ?
> These can be good example for test case, I think.

Fwiw, we have a dynamic graph (at probe time) today and Peter is looking 
into support for dynamic graph at runtime e.g. where Pipewire could 
build a graph like PCM -> Volume -> DRC -> Speaker

> 
>> I think that's a good place to start TBH - it's pretty much what we have
>> for DAPM with the DAPM lock.  We can always go back and rework things to
>> make the locking finer grained but hopefully that's not needed, we just
>> don't need to do things that take the lock for long enough or often
>> enough that people get worried about contention.
> 
> Thanks.
> Let's start with big lock, first.
> 
>> Yes, being able to work on this without needing some specific hardware
>> would be great - it's one of the big drawbacks with DPCM and one of the
>> things that make it fragile.  If we can get a good development and
>> testing setup that allows people to do work without needing to worry so
>> much about what other hardware will be impacted that would be a massive
>> win.
> 
> Nice to know
> 
>>> I have indicated many random topics, but these are just my idea.
>>> My motivation is I want to cleanup ASoC framework, but can't on soc-pcm,
>>> especially around DPCM. There is no guarantee I can create soc-pcm2, but
>>> have interesting. But what do you think ?
>>
>> I'm super greatful that you want to spend time tackling these things,
>> I think this is heading in roughly the right direction.
> 
> I'm busy for a while, but want to do this this year.
> I can enjoy this :)
> 
> I think the initial design is very important for soc-pcm2.
> So I will not care about detail things first (= sampling rate, channels,
> etc,...), but focus about graph / routing thinks. I think this is the
> main part for it.
> 
> Thank you for your help !!

One other thing I would say is that the audio hardware landscape is 
changing for client devices in that they are transitioning to Soundwire 
SDCA compliance over the next few years. This will probably impact IoT 
too as codec prices become lower over time, so I would recommend more 
focus on soundwire integration than say legacy HDA in pcm2 as this would 
probably help more in the long term.

Thanks

Liam

Re: ASoC: soc-pcm2.c ?

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1188 bytes --]

On Tue, Feb 03, 2026 at 06:07:00PM +0000, Liam Girdwood wrote:
> On 2/3/26 06:27, Kuninori Morimoto wrote:

> > Whether having default volume or not should not mandatory, should be just
> > option. We want to have flexible framework, like some board want to use same
> > style as before (= setup full routing etc via amixer), and/or some board want
> > to have default routing/volumes, etc.

> I think hiding any kcontrols or hard coding kcontrols that change audio
> processing or routing will break all client use cases, yes this may be nice
> on IoT where there is no sound server or userspace audio infra and very
> simple audio is needed, but on client we need the soundserver e.g. Pipewire,
> CRAS or audio HAL to configure and control the use case/policy.

Yeah, we need anything in this area to be some combination of opt in and
focused more on trying to pick defaults so there's less need to write
and distribute UCM configurations for trivial cases.  The things we can
do safely for everyone are pretty limited, things like hiding controls
that we know through routing to disconnected pins can never possibly be
part of a valid path (I always wanted to do that...) for example.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: ASoC: soc-pcm2.c ?

[Kuninori Morimoto]

Hi Liam

Thank you for your feedback

> Btw, I'm assuming pcm2 will reuse existing DAI and codec drivers but
> without the DAPM/DPCM flows ? i.e. same codec/dai binaries shipped by
> distros can be used by both pcm and pcm2 ?

pcm2 will not use DPCM.
CPU driver have no compatibility with pcm1 and pcm2.
If it was very very simple CPU driver, it might have some chance to conver
pcm1 CPU driver to pcm2 CPU driver, but almost 0 chance.

I'm not sure about DAPM so far, maybe reuse, maybe not.
Hopefully we want to keep Codec driver as-is, but not sure so far.

> DAPM is using "string match" method to check path/routing, but I want to
> use pointer style for it.
(snip)
> It should hopefully be easy to convert to an integer/pointer format here
> with some search/replace, however the mux enum controls reuse the
> strings in the kcontrol names IIRC so you may need to keep those.

Sorry my text was not clear.
I'm not sure how to do it, but my image is something like this

	[A] ----[C]
	[B] -+/

// [A]
struct mod mod_a {
	.name = "mod_a",
	...
};

// [B]
struct mod mod_b {
	.name = "mod_b",
	...
};

// [C]
struct mux mod_c = {
	.name = "mod_c",
	.inputs = { &mod_a,
		    &mod_b, },
};

	> amixer set "Mux mod_c input" "mod_a"
	> amixer set "Mux mod_c input" "mod_b"


> Whether having default volume or not should not mandatory, should be just
> option. We want to have flexible framework, like some board want to use same
> style as before (= setup full routing etc via amixer), and/or some board want
> to have default routing/volumes, etc.
(snip)
> I think hiding any kcontrols or hard coding kcontrols that change audio
> processing or routing will break all client use cases, yes this may be
> nice on IoT where there is no sound server or userspace audio infra and
> very simple audio is needed, but on client we need the soundserver e.g.
> Pipewire, CRAS or audio HAL to configure and control the use case/policy.

This is also maybe it was miss lead.
I want to say is like this. Because indicating image by ASCII art is
difficult, so it is using very simple case only.

	    [A]----[C]--[D]----[E] -->
	--> [B]-+/          \+-[F] -->
	                    \+-[G]

For example this chip has many inputs and many outputs, but used/connected
is only [B] (input) and [E]/[F] (output) for example.
From HW point of view, we need to select [C] input (= A or B), because
default is zero input. so we need to do this

	> amixer set "C input" "mod_b"

This is needed (from HW point of view), but is not needed (from user point
of view). I want to reduce it in pcm2.

And in the same time, from amixer point of view, current ASoC can do this

	> amixer set "D output" "mod_g"

But this is 100% not needed. This just increasing the number of amixer list
in this case. For example my case, we need to select via amixer is only 2 or
3, but amixer list indicated tons of settings. So I always indicate which
settings is needed on DT file, otherwise no one can use sound.

Maybe it is not related to PC user, but it makes embedded systems user
confuse (Please note that not PC user only is the Linux user, and not
all user have advanced userland).

And, if above [D] was DEMUX, I think there are 2 type of method.
One is like this. TYPE-A

	> aplay hw:0,0 // [E] output
	> aplay hw:0,1 // [F] output

Other is like this. TYPE-B

	> amixer set "demux D out" "mod_e"
	> aplay  // [E] output

	> amixer set "demux D out" "mod_f"
	> aplay  // [F] output

I don't intend to force TYPE-A. Someone want to use TYPE-A,
and someone want to use TYPE-B. But soc-pcm2 want to allow both case.
I think it depends on Card driver developer's design, though.

> One other thing I would say is that the audio hardware landscape is 
> changing for client devices in that they are transitioning to Soundwire 
> SDCA compliance over the next few years. This will probably impact IoT 
> too as codec prices become lower over time, so I would recommend more 
> focus on soundwire integration than say legacy HDA in pcm2 as this would 
> probably help more in the long term.

OK, thank you for your comment.





Thank you for your help !!

Best regards
---
Kuninori Morimoto

Re: ASoC: soc-pcm2.c ?

[Takashi Iwai]

On Tue, 03 Feb 2026 19:17:15 +0100,
Mark Brown wrote:
> 
> On Tue, Feb 03, 2026 at 06:07:00PM +0000, Liam Girdwood wrote:
> > On 2/3/26 06:27, Kuninori Morimoto wrote:
> 
> > > Whether having default volume or not should not mandatory, should be just
> > > option. We want to have flexible framework, like some board want to use same
> > > style as before (= setup full routing etc via amixer), and/or some board want
> > > to have default routing/volumes, etc.
> 
> > I think hiding any kcontrols or hard coding kcontrols that change audio
> > processing or routing will break all client use cases, yes this may be nice
> > on IoT where there is no sound server or userspace audio infra and very
> > simple audio is needed, but on client we need the soundserver e.g. Pipewire,
> > CRAS or audio HAL to configure and control the use case/policy.
> 
> Yeah, we need anything in this area to be some combination of opt in and
> focused more on trying to pick defaults so there's less need to write
> and distribute UCM configurations for trivial cases.  The things we can
> do safely for everyone are pretty limited, things like hiding controls
> that we know through routing to disconnected pins can never possibly be
> part of a valid path (I always wanted to do that...) for example.

That's a topic that has been discussed since many many years ago :)
Making all setups controllable via kconfig (that is user-space) is one
of key concepts in ASoC, but certainly that shows too much details to
anyone on the system.

Basically it should be relatively easy to implement a mechanism to
make kcontrols invisible, though; e.g. by introducing a new kcontrol
flag like SNDRV_CTL_ELEM_ACCESS_INVISIBLE, and some machine drivers or
codec drivers may set it up depending on the demands.
But justification to do that would become rather a bigger question.


thanks,

Takashi

Re: ASoC: soc-pcm2.c ?

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 814 bytes --]

On Wed, Feb 04, 2026 at 09:50:51AM +0100, Takashi Iwai wrote:

> Basically it should be relatively easy to implement a mechanism to
> make kcontrols invisible, though; e.g. by introducing a new kcontrol
> flag like SNDRV_CTL_ELEM_ACCESS_INVISIBLE, and some machine drivers or
> codec drivers may set it up depending on the demands.

We already have some support for marking controls as not visible by
default IIRC (I'm not immediately remembering the term that was used),
the trick is more finding a sensible way to turn it on - with so few
custom machine drivers these days it's much harder to enable sensibly.

> But justification to do that would become rather a bigger question.

Yes, the case where we know that what the control covers never has a
useful signal going through it is easy but people want more.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: ASoC: soc-pcm2.c ?

[Takashi Iwai]

On Wed, 04 Feb 2026 13:10:41 +0100,
Mark Brown wrote:
> 
> On Wed, Feb 04, 2026 at 09:50:51AM +0100, Takashi Iwai wrote:
> 
> > Basically it should be relatively easy to implement a mechanism to
> > make kcontrols invisible, though; e.g. by introducing a new kcontrol
> > flag like SNDRV_CTL_ELEM_ACCESS_INVISIBLE, and some machine drivers or
> > codec drivers may set it up depending on the demands.
> 
> We already have some support for marking controls as not visible by
> default IIRC (I'm not immediately remembering the term that was used),
> the trick is more finding a sensible way to turn it on - with so few
> custom machine drivers these days it's much harder to enable sensibly.

IIRC, the existing mechanism isn't about visibility but accessibility
via SNDRV_CTL_ELEM_ACCESS_INACTIVE flag.
kcontrols are still exposed to user-space unless they are explicitly
removed.


thanks,

Takashi

Re: ASoC: soc-pcm2.c ?

[Jaroslav Kysela]

On 2/4/26 13:21, Takashi Iwai wrote:
> On Wed, 04 Feb 2026 13:10:41 +0100,
> Mark Brown wrote:
>>
>> On Wed, Feb 04, 2026 at 09:50:51AM +0100, Takashi Iwai wrote:
>>
>>> Basically it should be relatively easy to implement a mechanism to
>>> make kcontrols invisible, though; e.g. by introducing a new kcontrol
>>> flag like SNDRV_CTL_ELEM_ACCESS_INVISIBLE, and some machine drivers or
>>> codec drivers may set it up depending on the demands.
>>
>> We already have some support for marking controls as not visible by
>> default IIRC (I'm not immediately remembering the term that was used),
>> the trick is more finding a sensible way to turn it on - with so few
>> custom machine drivers these days it's much harder to enable sensibly.
> 
> IIRC, the existing mechanism isn't about visibility but accessibility
> via SNDRV_CTL_ELEM_ACCESS_INACTIVE flag.
> kcontrols are still exposed to user-space unless they are explicitly
> removed.

But do we want to hide those controls completely ? They may be good for 
debugging. The new flag may be just a hint to user space to not show those 
controls by default (and eventually make it read only or locked for the user 
space - depends on the use).

				Jaroslav				

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

Re: ASoC: soc-pcm2.c ?

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 753 bytes --]

On Wed, Feb 04, 2026 at 01:33:29PM +0100, Jaroslav Kysela wrote:
> On 2/4/26 13:21, Takashi Iwai wrote:

> > IIRC, the existing mechanism isn't about visibility but accessibility
> > via SNDRV_CTL_ELEM_ACCESS_INACTIVE flag.
> > kcontrols are still exposed to user-space unless they are explicitly
> > removed.

> But do we want to hide those controls completely ? They may be good for
> debugging. The new flag may be just a hint to user space to not show those
> controls by default (and eventually make it read only or locked for the user
> space - depends on the use).

Yes, that was the idea - at least some of the userspaces won't show
those controls to users.  It also avoids reunumbering the controls in
case userspace is relying on the numbers.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: ASoC: soc-pcm2.c ?

[Péter Ujfalusi]

On 26/01/2026 08:41, Kuninori Morimoto wrote:
> 
> Hi ASoC ML
> 
> I have been cleanuping ASoC framework.
> I have started it after seeing Lars-Peter's presentation at ELC-E (almost
> 15 years ago ?). It was for updating ASoC framework.
> I have very agrred his idea, but I worried that it will be very difficult.
> Because in my opinion, controlling complex HW by complex SW is inpossible,
> and ASoC framwork was very complex. So I started to cleanup framework to
> help him.
> 
> I want to keep cleanuping, but one of the file which I can't cleanup is
> soc-pcm.c, especially around DPCM. I know how to use it, but I still can't
> undersand how it is working. I have talked it with Mark at OSS-Japan last
> year, and he had same/similar opinion.
> 
> For me, current DPCM looks like forcefully expanded functionality.
> I think support modern Sound HW on current DPCM is not impossible, but
> unique implementation is required on each vendor driver side.

I'm not sure what you mean by this, but since there are several codec
vendors and they produce different codecs, they do need to have
different drivers. Some needs more complex, some simpler and DAPM
provides the functionality for the developers to not care about the
things that are generic (sequencing, path finding, register/bit flips, etc).

> I think keeping cleanup/update current soc-pcm.c, and makes it more modern
> style is impossible or very difficult, and/or it may become irreversible code
> in worst case.
> 
> So may I suggest to create new soc-pcm2.c, like below ?
> 
> (A)	  soc-pcm.c
> (B)	+ soc-pcm2.c
> 	  ...
> 	  audio-graph-card2.c
> (C)	+ audio-graph-card3.c
> 
> All existing drivers uses existing soc-pcm.c (A). Nothing changed.
> And create new soc-pcm2.c (B) and new card driver, for example
> audio-graph-card3.c (C).
> audio-graph-card3 (C) user only can access to soc-pcm2 (B).
> 
> In this case, existing user will get zero damage from new soc-pcm2.c (B).
> We can just remove (B) and (C) file in worst case, it is easy to rollback.
> But what do you think ?

soc-pcm is much much more than just PCM, it is the 'backbone' of ASoC if
you will. It works tandem with DAPM, CPU/platform/codec drivers are part
of the system.

I'm not sure if I read this right, but the proposal is to create a
parallel and incompatible susbsystem?
How would existing codec drivers be used in there?
The promise of ASoC is that an OEM could pick any SoC and wire it up
with any codec and that will 'just work'.

> In my understanding, current DPCM searches path and power via DAPM in
> runtime. Because of it, the code become very complex. We would like to have
> more simple style in soc-pcm2.
> 
> OTOH, we need to call amixer to use Codec, like this
> 
> 	> amixer set "Mixin PGA" on
> 	> amixer set "Mixin PGA" 50%
> 	> amixer set "ADC" on
> 	> amixer set "ADC" 80%
> 	> amixer set "Aux" on
> 	> amixer set "Aux" 80%
> 	> amixer set "Mixin Left Aux Left" on
> 	> amixer set "Mixin Right Aux Right" on
> 	> amixer set "Mic 1" on
> 	> amixer set "Mic 1" 80%
> 	> amixer set "Mixin Left Mic 1" on
> 	> amixer set "Mixin Right Mic 1" on
> 
> This means, user need to understand Codec circuit and/or board schematic.
> Even if the path setting was correct, we can't get basinc sound without
> each volume settings, because default value is zero settings. We need to
> setup both "path" and "volumes" to use Codec.

This is why we have UCM, users should not need to know anything about
these controls, they should be able to say that I want to play audio to
headset and UCM will take care of the mixer changes.

fwiw, on one of my laptop (soundwire with Cirrus codec):
# amixer -c0 controls | wc -l
184
and I have never figured out how to switch manually as other laptop
needs completely different mixer changes for the same functionality,
lost cause w/o UCM.

> But it is not realistic premise IMO. I don't think *all* user understand
> it by themself. I think user don't need to care detail of HW. It should be
> handled by Kernel (= Kernel developer), not user, at least basic path and
> volume settings.
> At least, default path and default volume should be set by default without
> any settings from user, I think.
> 
> So I want to reduce amixer use case as much as possible somehow.

You cannot realistically do this, would you change all codec driver and
reduce their number of controls?

> Not zero, but volume control or some kind of feature

We could have several gain controls in a path, one main and then
separate ones per outputs/inputs, you cannot really remove these, you
cannot just control volume. What would you do if you play to two outputs
at the same time which shares one main gain control and gain on each
output? How to make only output 1 louder w/o changing output 2?

> (= for example "noise cancel") ON/OFF only, etc.
> 
> 
> I'm now thinking for soc-pcm2 is that we can use "graph" and "routing" ?
> Here "graph" means, physical HW connections, like below
> 
> 	+---- CPU ----------+    +----- Codec -------+
> 	|                   |    |                   |
>     -->	| [A]--+-[C]-+--[D] | -- | [a]--+-[b]-+--[c] | ->
>     -->	| [B]-/             |    |             \-[d] | ->
> 	+-------------------+    +-------------------+
> 
> This is very simple graph image.
> [C] is Mixer
> [b] is selector
> Others are some kind of features.
> 
> And "routing" is for example
> 
> 	1: [A]-[C]-[D]-[a]-[b]-[c]
> 	2: [A]-[C]-[D]-[a]-[b]-[d]
> 	3: [B]-[C]-[D]-[a]-[b]-[c]
> 	4: [B]-[C]-[D]-[a]-[b]-[d]
> 
> In Codec, each [x] connections are handled by DAPM, in my understanding,
> but we don't have such code for CPU side today.
> I think DAPM is for "Power Management", but is same as "routing".
> I think we can expand it or create similar system for CPU too ?
> 
> Anyway, both "graph" and "routing" are fixed, not changed after boot.
> No need to search path in runtime in this idea. So no need to call amixer
> (for path setting. It wil be setup from inside kernel, etc).
> Above "graph" is good match to modern Sound HW ?
> 
> In this case, device number = path, like this
> 
> 	> aplay -D hw:0,1 // path 1:
> 	> aplay -D hw:0,2 // path 2:
> 	...

With current setup you only need to flip a control to move the audio
from c to d which would be as silent affair as possible thanks to DAPM.
With separate PCM devices you would need to close stream 1 (shut down
codec) then open another stream (seek into the audio where you closed
the stream 1), this would likely cause pop issues and other issues.

It is another matter when you need to have separate PCM devices per
endpoint (like with soundwire). There we use DAPM as well to make sure
that the path is powered on.

> It will just fail if some path can't work in the same time,
> for example above 1 vs 2.
> Good point is that no runtime search is needed (= can be simple code),
> Bad point is that number of "routing" can be explosion, but it is very
> rare cases ?

apart from the explosion you also need to enforce some sort of standard
on PCM device indexes and names which would scale to a system with only
single jack to one with 10 jack and speakers and S/PDIF and coax and HDMI.

You would always need user space to handle this and UCM is the current
solution for abstracting the complexity. Yes, it has it's limitation,
but covers most of the cases pretty well and if not, can be extended.

> Sound HW/system is very complex, and ASoC allows .trigger and .hw_param
> etc in the same time. So we need to have many locks (for each modules, for
> routing, etc). Because of this, current ASoC has tons of locks, and need
> complex lockdep ?
> 
> I know this is not so good idea, but how about to have only one lock, like
> "graph lock" ? This is just opinion, but having one large lock is not so
> good idea, but better than very complex and un-controllable code.
> I don't think .trigger and .hw_param are called frequently in the same time...
> Yes, maybe realtime side can be problem though...

ALSA have per PCM lock to open, triggers, but ASoC and DAPM can reach
out from one PCM lock to a path which is protected by other PCM lock and
could do a mess of things.
With SOF we deal with DSP topology on top of all this and needed another
set of locks to tame the concurrency of ALSA and ASoC...

> I think we can use existing Codec driver as-is in soc-pcm2, but, CPU driver
> needs to be re-maked (?), especially DPCM user. But not sure...

Codec drivers rely on DAPM + soc-pcm callbacks, how can they be re-used
in a different susbystem?

> If I create soc-pcm2.c, I will create sample CPU driver and its sample DTSI
> file, like ${LINUX}/sound/sbboc/generic/audio-graph-card2-custom-sample1.dtsi.
> People can easily try/test it by just including it in your DTSI file.
> No HW / no implementation is needed for testing. And I think it can be good
> sample code to create new CPU driver ?

We use ASoC on non OF machines as well, I understand that the current
users will not be affected, but having a parallel ecosystem sounds a bit
scary proposal for ASoC to move forward?

> I have indicated many random topics, but these are just my idea.
> My motivation is I want to cleanup ASoC framework, but can't on soc-pcm,
> especially around DPCM. There is no guarantee I can create soc-pcm2, but
> have interesting. But what do you think ?
> 
> Thank you for your help !!
> 
> Best regards
> ---
> Kuninori Morimoto
> 

-- 
Péter

Re: ASoC: soc-pcm2.c ?

[Péter Ujfalusi]

On 03/02/2026 09:45, Péter Ujfalusi wrote:
>> I'm now thinking for soc-pcm2 is that we can use "graph" and "routing" ?
>> Here "graph" means, physical HW connections, like below
>>
>> 	+---- CPU ----------+    +----- Codec -------+
>> 	|                   |    |                   |
>>     -->	| [A]--+-[C]-+--[D] | -- | [a]--+-[b]-+--[c] | ->
>>     -->	| [B]-/             |    |             \-[d] | ->
>> 	+-------------------+    +-------------------+

In a simplified way we have similar setup with SOF where we can have as
many PCM devices (A/B/C/D) mixed within a DSP and sent to a DAI and to a
codec, each PCM can have different properties, even you can havce a
compr device sent over and mixed.

>>
>> This is very simple graph image.
>> [C] is Mixer
>> [b] is selector
>> Others are some kind of features.
>>
>> And "routing" is for example
>>
>> 	1: [A]-[C]-[D]-[a]-[b]-[c]
>> 	2: [A]-[C]-[D]-[a]-[b]-[d]
>> 	3: [B]-[C]-[D]-[a]-[b]-[c]
>> 	4: [B]-[C]-[D]-[a]-[b]-[d]
>>
>> In Codec, each [x] connections are handled by DAPM, in my understanding,
>> but we don't have such code for CPU side today.
>> I think DAPM is for "Power Management", but is same as "routing".
>> I think we can expand it or create similar system for CPU too ?
>>
>> Anyway, both "graph" and "routing" are fixed, not changed after boot.
>> No need to search path in runtime in this idea. So no need to call amixer
>> (for path setting. It wil be setup from inside kernel, etc).

I see, so basically you want to scan the DAPM graph on boot and create
as many PCM devices as many DAPM route can be built (platform/cpu_dai ->
codec_dai -> codec_output and same for inputs) by walking and tracing
the mixers/muxes?

Create virtual PCM devices which would map to real PCM device underneath
(which is a platform+cpu_dai as this is the constraint to move data
from/to host).

I guess it might be an interesting experiment to wrap the current ASoC
inside of a virtual PCM wrap and expose paths as PCMs. probably can be
done with asoundrc magic as well.

>> Above "graph" is good match to modern Sound HW ?

Depends on the definition of modern sound hardware ;)

In SOF we kind of doing similarish things for PCM devices and DSP
topology, but we don't want to rewrite the codec side of things.
PCMs are 'linked' to DAIs on the other side of the DSP and the path
within DSP is sort of static, we could do dynamic path changes, but so
far this has not something that came as a need.
We use DAPM for graph for the in DSP path.
Something like this for example:
https://sof-ci.01.org/linuxpr/PR5647/build10053/devicetest/PTLH_HDA_AIOC/sof-hda-generic-ace3-4ch.png

host-copier.0 is PCM0 (playback, normal)
host-copier.31 is PCM31 (playback DeepBuffer)
both is route to one HDA analog and from there it is the codec who does
the routing to speaker/headphone, we don't care.

We push this a bit further for few setups, like:
https://sof-ci.01.org/linuxpr/PR5647/build10053/devicetest/PTLH_RVP_NOCODEC/sof-ptl-nocodec.png

Probably the path walk would be possible to be done during probe and
then just run through the list, but this is just how things are
currently and 'simplifying' this would limit future possibilities which
we don't see yet to come.

We might want to divert, add/remove component in the path, we might want
to move the stream from one endpoint to another within DSP and w/o
closing the PCM device, I don't know. Might not happen at all...

>> In this case, device number = path, like this
>>
>> 	> aplay -D hw:0,1 // path 1:
>> 	> aplay -D hw:0,2 // path 2:
>> 	...
> 
> With current setup you only need to flip a control to move the audio
> from c to d which would be as silent affair as possible thanks to DAPM.
> With separate PCM devices you would need to close stream 1 (shut down
> codec) then open another stream (seek into the audio where you closed
> the stream 1), this would likely cause pop issues and other issues.
> 
> It is another matter when you need to have separate PCM devices per
> endpoint (like with soundwire). There we use DAPM as well to make sure
> that the path is powered on.
> 
>> It will just fail if some path can't work in the same time,
>> for example above 1 vs 2.
>> Good point is that no runtime search is needed (= can be simple code),
>> Bad point is that number of "routing" can be explosion, but it is very
>> rare cases ?
> 
> apart from the explosion you also need to enforce some sort of standard
> on PCM device indexes and names which would scale to a system with only
> single jack to one with 10 jack and speakers and S/PDIF and coax and HDMI.
> 
> You would always need user space to handle this and UCM is the current
> solution for abstracting the complexity. Yes, it has it's limitation,
> but covers most of the cases pretty well and if not, can be extended.
> 
>> Sound HW/system is very complex, and ASoC allows .trigger and .hw_param
>> etc in the same time. So we need to have many locks (for each modules, for
>> routing, etc). Because of this, current ASoC has tons of locks, and need
>> complex lockdep ?
>>
>> I know this is not so good idea, but how about to have only one lock, like
>> "graph lock" ? This is just opinion, but having one large lock is not so
>> good idea, but better than very complex and un-controllable code.
>> I don't think .trigger and .hw_param are called frequently in the same time...
>> Yes, maybe realtime side can be problem though...
> 
> ALSA have per PCM lock to open, triggers, but ASoC and DAPM can reach
> out from one PCM lock to a path which is protected by other PCM lock and
> could do a mess of things.
> With SOF we deal with DSP topology on top of all this and needed another
> set of locks to tame the concurrency of ALSA and ASoC...
> 
>> I think we can use existing Codec driver as-is in soc-pcm2, but, CPU driver
>> needs to be re-maked (?), especially DPCM user. But not sure...
> 
> Codec drivers rely on DAPM + soc-pcm callbacks, how can they be re-used
> in a different susbystem?
> 
>> If I create soc-pcm2.c, I will create sample CPU driver and its sample DTSI
>> file, like ${LINUX}/sound/sbboc/generic/audio-graph-card2-custom-sample1.dtsi.
>> People can easily try/test it by just including it in your DTSI file.
>> No HW / no implementation is needed for testing. And I think it can be good
>> sample code to create new CPU driver ?
> 
> We use ASoC on non OF machines as well, I understand that the current
> users will not be affected, but having a parallel ecosystem sounds a bit
> scary proposal for ASoC to move forward?
> 
>> I have indicated many random topics, but these are just my idea.
>> My motivation is I want to cleanup ASoC framework, but can't on soc-pcm,
>> especially around DPCM. There is no guarantee I can create soc-pcm2, but
>> have interesting. But what do you think ?
>>
>> Thank you for your help !!
>>
>> Best regards
>> ---
>> Kuninori Morimoto
>>
> 

-- 
Péter

Re: ASoC: soc-pcm2.c ?

[Kuninori Morimoto]

Hi Peter

Thank you for your feedback

> For me, current DPCM looks like forcefully expanded functionality.
> I think support modern Sound HW on current DPCM is not impossible, but
> unique implementation is required on each vendor driver side.
(snip)
> I'm not sure what you mean by this, but since there are several codec
> vendors and they produce different codecs, they do need to have
> different drivers. Some needs more complex, some simpler and DAPM
> provides the functionality for the developers to not care about the
> things that are generic (sequencing, path finding, register/bit flips, etc).

Hmm ?
I   was indicating DPCM
you are indicating DAPM ?

> I'm not sure if I read this right, but the proposal is to create a
> parallel and incompatible susbsystem?

Yes
Because update existing soc-pcm without damage seems impossile.

> How would existing codec drivers be used in there?

Maybe reused, maybe not. Nothing is decided yet.
That is the reason why I'm sending this kind of mail.

> This is why we have UCM, users should not need to know anything about
> these controls, they should be able to say that I want to play audio to
> headset and UCM will take care of the mixer changes.

Please consider about non PC user case, too.
I have mentioned about this topic in other mail. Please check it.

> You cannot realistically do this, would you change all codec driver and
> reduce their number of controls?

As I mentioned on previous mail, I have no plan to update existing drivers
for pcm2. Maybe small update might be happen, though

> We could have several gain controls in a path, one main and then
> separate ones per outputs/inputs, you cannot really remove these, you
> cannot just control volume. What would you do if you play to two outputs
> at the same time which shares one main gain control and gain on each
> output? How to make only output 1 louder w/o changing output 2?

Sorry, my explanation was not clear for you. I never indicate to remove all
settings. I have mentioned was like this

	    [A]----[C]--[D]----[E] -->
	--> [B]-+/          \+-[F] -->
	                    \+-[G]

In current ASoC, it uses default settings. for example above case,
we need to setup routing for [C] and [D], otherwise there is no sound.

Here, normal user who don't use advanced userland (= can't use UCM), need
to get its datasheet and its board schematic. And investigate connections
and amixer list, etc, etc, etc...

And more, as you mentioned, let's think about for example [B] [C] [E] needs
to setup volume. If normal user could setup routing connection, like
[B][C][D][E], he still get zero sound, because it is using 0 volume as
HW default. So he will think that the routing was still not good, and will
change the correct routing settings.

This is not realistic. Please note that not all user can use advanced
userland, and not all Linux users are PC user.

But in above case, input of [C] is only [B], and maybe almost all user try
to uses [E] as 1st for example. In this case, we want to have default
routing settings for [C] [D] (without UCM), and default volume for
[B] [C] [E]. This is under Card driver developer's design.
In this case normal user can get sound from [E] without any settings.

This doesn't mean pcm2 removes all settings. User or UCM can setup
(= overwrite) routing of [D], and volume of [B] [C] [E], same as before.
No need to setup [C], because it is fixed route.
And it will not appear on amixer list.

Please check also my other mail, today.

> Codec drivers rely on DAPM + soc-pcm callbacks, how can they be re-used
> in a different susbystem?

Why pcm2 can't call it ? 

> We use ASoC on non OF machines as well, I understand that the current
> users will not be affected, but having a parallel ecosystem sounds a bit
> scary proposal for ASoC to move forward?

Existing system will not be removed, and will not get damage/effect from
pcm2. And, I will never forcing you to use pcm2.
If you don't like it, you just ignore it and use pcm1, same as today.

We can just remove pcm2 code if it failed. It has zero effect to pcm1 user.
This means, existing pcm1 user will get zero damage/effect from pcm2
anyway whether it succeed or failed.

If pcm2 was failed, nothing is changed.
If pcm2 was succeed, you will get +1 option.

Thank you for your help !!

Best regards
---
Kuninori Morimoto

Re: ASoC: soc-pcm2.c ?

[Péter Ujfalusi]

Hi Morimoto-san,

On 04/02/2026 09:28, Kuninori Morimoto wrote:
> 
> Hi Peter
> 
> Thank you for your feedback
> 
>> For me, current DPCM looks like forcefully expanded functionality.
>> I think support modern Sound HW on current DPCM is not impossible, but
>> unique implementation is required on each vendor driver side.
> (snip)
>> I'm not sure what you mean by this, but since there are several codec
>> vendors and they produce different codecs, they do need to have
>> different drivers. Some needs more complex, some simpler and DAPM
>> provides the functionality for the developers to not care about the
>> things that are generic (sequencing, path finding, register/bit flips, etc).
> 
> Hmm ?
> I   was indicating DPCM
> you are indicating DAPM ?

It has not been clean on what this proposal about, we don't have much
kcontrol or mixer elements to control PCM on SoC side, so kcontrol for
me is associated with DAPM mostly.

>> How would existing codec drivers be used in there?
> 
> Maybe reused, maybe not. Nothing is decided yet.
> That is the reason why I'm sending this kind of mail.

The maybe not option would be really bad for overall ASoC, I don't think
it is viable to expect two different 'generic' framework with duplicated
drivers.

>> This is why we have UCM, users should not need to know anything about
>> these controls, they should be able to say that I want to play audio to
>> headset and UCM will take care of the mixer changes.
> 
> Please consider about non PC user case, too.
> I have mentioned about this topic in other mail. Please check it.

UCM was created for non PC environment initially and later adapted to be
used on PCs as well.

> 
>> You cannot realistically do this, would you change all codec driver and
>> reduce their number of controls?
> 
> As I mentioned on previous mail, I have no plan to update existing drivers
> for pcm2. Maybe small update might be happen, though
> 
>> We could have several gain controls in a path, one main and then
>> separate ones per outputs/inputs, you cannot really remove these, you
>> cannot just control volume. What would you do if you play to two outputs
>> at the same time which shares one main gain control and gain on each
>> output? How to make only output 1 louder w/o changing output 2?
> 
> Sorry, my explanation was not clear for you. I never indicate to remove all
> settings. I have mentioned was like this
> 
> 	    [A]----[C]--[D]----[E] -->
> 	--> [B]-+/          \+-[F] -->
> 	                    \+-[G]
> 
> In current ASoC, it uses default settings. for example above case,
> we need to setup routing for [C] and [D], otherwise there is no sound.
> 
> Here, normal user who don't use advanced userland (= can't use UCM), need
> to get its datasheet and its board schematic. And investigate connections
> and amixer list, etc, etc, etc...

Well, if the driver is written incorrectly and needs user action to
connect C to D, then it is not a framework issue, but a driver issue.

static const struct snd_soc_dapm_route intercon[] = {
	{"C", NULL, "A"},
	{"C", NULL, "B"},
	{"D", NULL, "C"},
	...
};

If there are registers to flip, then a virtual widget and all works w/o
user interaction.

But you cannot aplay to G as such, that is true, but this is not a PCM,
it is how DAPM compares to your proposal.

DAPM uses graph as well, it will walk from source and enable things in a
path towards an output, if there is one. If there are multiple outputs,
it will power on all of the paths.

Your proposal is to create separate PCM device for each possible routes,
record what mixers/muxes/switches (if any) in the path should be set to
what value and if run that 'script' when the PCM is started.
In a way moving from DAPM to SAPM (Dynamic to Static Audio Power
Management).

DAPM would be able to do this if you have virtual PCMs, but the current
limitation is that a PCM is tied to a DMA channel, which is sort of
understandable as from ALSA buffer you need to move the data to DAI and
that is a DMA, but still, one can do this currently (I think
omap-mcpdm+twl6040 can do similar thing).
But it would be convoluted to say the least.

If I think about this, I think the topology is sort of provides this
description, which we use in SOF as well. It describes the path in
digital domain - within the DSP - and creates a DAPM path.
This could expose kcontrol or be a silent path without user visible
controls.

> And more, as you mentioned, let's think about for example [B] [C] [E] needs
> to setup volume. If normal user could setup routing connection, like
> [B][C][D][E], he still get zero sound, because it is using 0 volume as
> HW default. So he will think that the routing was still not good, and will
> change the correct routing settings.

Oh, how many times I have faced with this ;)

> This is not realistic. Please note that not all user can use advanced
> userland, and not all Linux users are PC user.

UCM is far from advanced userland...

For a board which is available for user, it is not a big ask to have UCM
profile, given if it can run Linux.
Average user will unlikely to create a custom board with audio and then
wonder how it works.

> But in above case, input of [C] is only [B], and maybe almost all user try
> to uses [E] as 1st for example. In this case, we want to have default
> routing settings for [C] [D] (without UCM), and default volume for
> [B] [C] [E]. This is under Card driver developer's design.
> In this case normal user can get sound from [E] without any settings.

Right, this can be already done in machine driver afaik?

> This doesn't mean pcm2 removes all settings. User or UCM can setup
> (= overwrite) routing of [D], and volume of [B] [C] [E], same as before.
> No need to setup [C], because it is fixed route.
> And it will not appear on amixer list.

As I said, C-D connection should not appear for user, unless you want to
expose a hard mute...

> Please check also my other mail, today.
> 
>> Codec drivers rely on DAPM + soc-pcm callbacks, how can they be re-used
>> in a different susbystem?
> 
> Why pcm2 can't call it ? 

Sure, but why pcm2 can use DAPM as underlying graph infra?

>> We use ASoC on non OF machines as well, I understand that the current
>> users will not be affected, but having a parallel ecosystem sounds a bit
>> scary proposal for ASoC to move forward?
> 
> Existing system will not be removed, and will not get damage/effect from
> pcm2. And, I will never forcing you to use pcm2.
> If you don't like it, you just ignore it and use pcm1, same as today.

And that is a bad target, having two incompatible susbsystems will cause
burden for maintainers, vendors, OEMs and contributors alike. Where to
focus on new development? Should we improve both or only one? how one
decides which is used for which SoC and board? Same SoC might need
different susbsystem because of other external factors (codec drivers, etc).

> We can just remove pcm2 code if it failed. It has zero effect to pcm1 user.
> This means, existing pcm1 user will get zero damage/effect from pcm2
> anyway whether it succeed or failed.
> 
> If pcm2 was failed, nothing is changed.
> If pcm2 was succeed, you will get +1 option.

Improving DPMC has always on the plate and given how basic it is (BE and
FE), it is a great idea.
In SOF (and in topology) we use DAPM within DPCM for route management -
but  not for it's Power control.

> Thank you for your help !!
> 
> Best regards
> ---
> Kuninori Morimoto
> 

-- 
Péter

Re: ASoC: soc-pcm2.c ?

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2031 bytes --]

On Tue, Feb 03, 2026 at 09:45:50AM +0200, Péter Ujfalusi wrote:
> On 26/01/2026 08:41, Kuninori Morimoto wrote:

> > For me, current DPCM looks like forcefully expanded functionality.
> > I think support modern Sound HW on current DPCM is not impossible, but
> > unique implementation is required on each vendor driver side.

> I'm not sure what you mean by this, but since there are several codec
> vendors and they produce different codecs, they do need to have
> different drivers. Some needs more complex, some simpler and DAPM
> provides the functionality for the developers to not care about the
> things that are generic (sequencing, path finding, register/bit flips, etc).

AIUI the issue referred to there is on the SoC side - DPCM doesn't
support SoC drivers as much as CODEC drivers due to the lack of
framework features for dealing with digital parameters.

> I'm not sure if I read this right, but the proposal is to create a
> parallel and incompatible susbsystem?
> How would existing codec drivers be used in there?
> The promise of ASoC is that an OEM could pick any SoC and wire it up
> with any codec and that will 'just work'.

AIUI the idea is to only rework the SoC side.

> > If I create soc-pcm2.c, I will create sample CPU driver and its sample DTSI
> > file, like ${LINUX}/sound/sbboc/generic/audio-graph-card2-custom-sample1.dtsi.
> > People can easily try/test it by just including it in your DTSI file.
> > No HW / no implementation is needed for testing. And I think it can be good
> > sample code to create new CPU driver ?

> We use ASoC on non OF machines as well, I understand that the current
> users will not be affected, but having a parallel ecosystem sounds a bit
> scary proposal for ASoC to move forward?

We'd have to work out some way to flip the switch for ACPI systems at
some point, I guess there it'd be either a command line parameter or a
build option (which we'd probably end up with at some point for DT
systems once things are more ready).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: ASoC: soc-pcm2.c ?

[Péter Ujfalusi]

On 03/02/2026 18:18, Mark Brown wrote:
> On Tue, Feb 03, 2026 at 09:45:50AM +0200, Péter Ujfalusi wrote:
>> I'm not sure what you mean by this, but since there are several codec
>> vendors and they produce different codecs, they do need to have
>> different drivers. Some needs more complex, some simpler and DAPM
>> provides the functionality for the developers to not care about the
>> things that are generic (sequencing, path finding, register/bit flips, etc).
> 
> AIUI the issue referred to there is on the SoC side - DPCM doesn't
> support SoC drivers as much as CODEC drivers due to the lack of
> framework features for dealing with digital parameters.

That is true, within SOF framework we have our own implementation of
passing PCM parameters along the path and modules can change those -
8KHz mono from aplay leaves the DSP as 48KHz stereo and from there it
goes to the codec.
We pigyback on DAPM/DPCM for some graph work.

>> I'm not sure if I read this right, but the proposal is to create a
>> parallel and incompatible susbsystem?
>> How would existing codec drivers be used in there?
>> The promise of ASoC is that an OEM could pick any SoC and wire it up
>> with any codec and that will 'just work'.
> 
> AIUI the idea is to only rework the SoC side.

Up to DAI, including DSPs?
SoC side is in simplest term is platform (DMA) + DAI, when it becomes
more interesting/challenging is when you have platform (DMA) + DSP + DAI
on the SoC side - and then another DSP on the codec side.

>>> If I create soc-pcm2.c, I will create sample CPU driver and its sample DTSI
>>> file, like ${LINUX}/sound/sbboc/generic/audio-graph-card2-custom-sample1.dtsi.
>>> People can easily try/test it by just including it in your DTSI file.
>>> No HW / no implementation is needed for testing. And I think it can be good
>>> sample code to create new CPU driver ?
> 
>> We use ASoC on non OF machines as well, I understand that the current
>> users will not be affected, but having a parallel ecosystem sounds a bit
>> scary proposal for ASoC to move forward?
> 
> We'd have to work out some way to flip the switch for ACPI systems at
> some point, I guess there it'd be either a command line parameter or a
> build option (which we'd probably end up with at some point for DT
> systems once things are more ready).

My concern is more of a parallel and incompatible ecosystem which might
force duplicated drivers. This is what is not clear and could cripple
the benefit of ASoC and we are back in sort of pre ASoC tightly
integrated world.

-- 
Péter

Re: ASoC: soc-pcm2.c ?

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1812 bytes --]

On Wed, Feb 04, 2026 at 12:18:13PM +0200, Péter Ujfalusi wrote:
> On 03/02/2026 18:18, Mark Brown wrote:
> > On Tue, Feb 03, 2026 at 09:45:50AM +0200, Péter Ujfalusi wrote:

> >> I'm not sure if I read this right, but the proposal is to create a
> >> parallel and incompatible susbsystem?
> >> How would existing codec drivers be used in there?
> >> The promise of ASoC is that an OEM could pick any SoC and wire it up
> >> with any codec and that will 'just work'.

> > AIUI the idea is to only rework the SoC side.

> Up to DAI, including DSPs?
> SoC side is in simplest term is platform (DMA) + DAI, when it becomes
> more interesting/challenging is when you have platform (DMA) + DSP + DAI
> on the SoC side - and then another DSP on the codec side.

Yes, the problem with the SoC side is that it only really copes with a
simple DMA/DAI combo and struggles with anything like DSPs.

> > We'd have to work out some way to flip the switch for ACPI systems at
> > some point, I guess there it'd be either a command line parameter or a
> > build option (which we'd probably end up with at some point for DT
> > systems once things are more ready).

> My concern is more of a parallel and incompatible ecosystem which might
> force duplicated drivers. This is what is not clear and could cripple
> the benefit of ASoC and we are back in sort of pre ASoC tightly
> integrated world.

I agree it's not ideal, but my expectation is that it's just the SoC
side which is already like that.  The flip side of the concern is that
we've had these ideas for more than a decade and not made much progress
on them, and whenever there's work on DPCM it's been fairly difficult
and error prone with all the different platforms which doesn't bode well
for trying to do in place refactoring.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]