On Thu 30 Apr 2020 at 14:41, Sameer Pujar spujar@nvidia.com wrote:

At a high level Tegra Audio HW is depicted as below.

| Front End PCMs | SoC DSP | Back End DAIs |

                     *************

ADMAIF<0> <------------> * * <----DAI<0>-----> I2S * * ADMAIF<1> <------------> * * <----DAI<1>-----> DMIC * XBAR * ADMAIF<2> <------------> * * <----DAI<2>-----> DSPK * * ADMAIF<N> <------------> * * <----DAI<3>-----> SFC (Resampler) * * * * <----DAI<4>-----> MIXER * * * * <----DAI<N>-----> ... *************

Follow up queries

Based on the above experience I do have few follow up queries and request for your inputs on this.

a) Can I use a DAPM Mux control to activate a BE path? This in turn can program required switch in XBAR.

My 2 cents: DPCM should activate any BE which has: * a valid DAPM path from the current FE * a valid BE stream (ex: can handle the stream direction)

AFAIK, you can use any combination of DAPM elements to model your components, including the XBAR. Then, it is the job of the card driver to link the DAPM widgets of the different components together and bring the system to life.

If your XBAR is widgets are not provided by a component which also provides a dai_link in the sound card, you'll need to add the component to the auxiliary device list of the card for the widget to be available in the card.

This is needed for following reasons:

- For an open platform like Jetson, we want to give maximum flexibility
  for a user to customize their audio paths. Number of connected
  components and order of these can vary depending on a use case.

- Allow re-use of audio components across multiple use cases.
  For example, number of SFC instances are lesser than PCM playback or
  capture devices.

b) I have modelled SFC and MIXER as backends. Is this allowed?

This was done to include SFC or MIXER HW components as part of the
sound card and use like below in one of the audio use cases.

ADMAIF1(FE) --> SFC(BE1) --> I2S(BE2) ... OR
ADMAIF2(FE) --> SFC(BE1) --> I2S(BE2) ...

What your are trying to achieve here is DAI chaining. From the DAPM perspective, it is alright. Unfortunately this kind of chaining are not supported (not yet, at least) from the dai_link perspective, even with DPCM.

From the DPCM perspective, I think your patch does the following:

ADMAIF1(FE) ---> SFC(BE1) |--> I2S(BE2) ADMAIF2(FE) ---> SFC(BE1) |--> I2S(BE2)

Your DAIs are not chained, but put in parallel. Maybe all your DAI callbacks are called in a way that is convinient enough for your use cases, but it is not what you intended.

For the example, the rate passed to 'I2S(BE2)' in hw_params() will be the one provided by the 'ADMAIF', not the output rate of the 'SFC'.

I used following workaround to connect multiple BE components.
With this I can see PCM callbacks happen for all BE DAIs along the DAPM
path. The obective was to connect multiple components together and (a)
was used to connect one component to another. Each "-->" here connects
two components and it is a switch in XBAR. 

---
  sound/soc/soc-pcm.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

  diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c
  index e256d43..ee7af55 100644
  --- a/sound/soc/soc-pcm.c
  +++ b/sound/soc/soc-pcm.c
  @@ -1494,7 +1494,7 @@ int dpcm_path_get(struct snd_soc_pcm_runtime *fe,

 /* get number of valid DAI paths and their widgets */
 paths = snd_soc_dapm_dai_get_connected_widgets(cpu_dai, stream, list,
  -			dpcm_end_walk_at_be);
  +			NULL);

dev_dbg(fe->dev, "ASoC: found %d audio %s paths\n", paths, stream ? "capture" : "playback"); --

c) Hostless mode did NOT work: - Following audio path was intended to be tested: I2S1 --> SFC --> I2S2

 - [3] offers two options:
     * CODEC<->CODEC: If I were to use a separate DAI link for each BE to BE
       connection, then it will result in a similar design what we have
       currently.

     * Hostless: I did not come across references for this.
       (Any references in this regard will be helpful)

May be the current Tegra ASoC design is more suitable for component model as you had previously mentioned. I wanted to understand if above, especially (a) and (b), are acceptable in this regard or if there are better options to interconnect multiple ASoC components.

Looking forward for your feedback.

Thanks, Sameer.

References

[0] http://patchwork.ozlabs.org/project/linux-tegra/list/?series=159664&arch... [1] http://patchwork.ozlabs.org/project/linux-tegra/patch/1582180492-25297-6-git... [2] http://patchwork.ozlabs.org/project/linux-tegra/patch/1582180492-25297-4-git... [3] https://www.kernel.org/doc/html/v5.6/sound/soc/dpcm.html