topology2: add src support

[RanderWang]

This PR add ipc src support in topology2.

[RanderWang]

updated, thanks

[RanderWang]

change it to RFC since we need to support
(1) all the formats. The debugging and validation effort will be significantly increased
(2) add mixin & mixout

[RanderWang]

@plbossart @lgirdwood @ranj063 @bardliao I have an idea bout SRC support in Linux kernel.
SOF can support many sample rates but it is not optimized to build it in topology. The reason is that 48khz audio file will be used in 4x% chance, 4x% 44.1khz and n% for other sample rates. If SRC is built in topology it will introduce more cpu usage for normal 48khz audio. It is not a good deal.

My solution is dynamically add SRC in driver according to sample rate so that we have optimized performance. Another way is to build it in topology but delete it in driver for no conversion rate.

[lgirdwood]

@plbossart @lgirdwood @ranj063 @bardliao I have an idea bout SRC support in Linux kernel. SOF can support many sample rates but it is not optimized to build it in topology. The reason is that 48khz audio file will be used in 4x% chance, 4x% 44.1khz and n% for other sample rates. If SRC is built in topology it will introduce more cpu usage for normal 48khz audio. It is not a good deal.

My solution is dynamically add SRC in driver according to sample rate so that we have optimized performance. Another way is to build it in topology but delete it in driver for no conversion rate.

@RanderWang just a thought, rather than expressing all the supported in/out rates for the SRC in the topology, we could use a wildcard rate (like SNDRV_PCM_RATE_CONTINUOUS using 0) which means we can define a single SRC object with wildcard in/out rates where the FW could reject any invalid combination.

[plbossart]

@plbossart @lgirdwood @ranj063 @bardliao I have an idea bout SRC support in Linux kernel. SOF can support many sample rates but it is not optimized to build it in topology. The reason is that 48khz audio file will be used in 4x% chance, 4x% 44.1khz and n% for other sample rates. If SRC is built in topology it will introduce more cpu usage for normal 48khz audio. It is not a good deal.

My solution is dynamically add SRC in driver according to sample rate so that we have optimized performance. Another way is to build it in topology but delete it in driver for no conversion rate.

That's what others have suggested in the 'AVS' driver, you could bind modules only if required, e.g. if you don't need an instance of SRC you can bypass the SRC.

The problem is that it's of course a lot more complicated to decide whether to bind or not. This would not work for e.g. multiple steps of conversions, because at the moment the DPCM driver cannot be informed of possible rate changes.

Also the introduction of the SRC is a nice feature, but who needs it? In practice, sound servers (CRAS, PulseAudio, etc) already resample to a desired rate, so it's not like we can expect tons of different configurations. Specifically the 44.1kHz case is not required, we've lived since 2013 without SRC in the firmware and no one ever complained about the host-based conversion.

And last, SRC takes resources that could be used for other things that have more added value, such as branded processing, speaker amp. SRC is an item on a program manager checklist, its value as part of the firmware is very very questionable with very very limited returned IMHO. I vote that we don't spend too much time on the optimization and just focus on getting SRC to work. It remains to be seen whether this will actually be used in a product.

[RanderWang]

updated.
(1) support all the rate from 8k to 192k
(2) add mixer support

Validated on ADL

[RanderWang]

updated, thanks!

[singalsu]

Looks OK to me for discussed part: frames count calculation.

[XiaoyunWu6666]

Hi @RanderWang , this PR seem to cause some error in cavs-mixin-mixout-hda.tplg and cause multiple IPC4 HDA platforms failed to load the tplg correctly.
Do you have any idea? Thanks

[bardliao]

Hi @RanderWang , this PR seem to cause some error in cavs-mixin-mixout-hda.tplg and cause multiple IPC4 HDA platforms failed to load the tplg correctly. Do you have any idea? Thanks

@XiaoyunWu6666 Please try #5971