Re: More Generic Audio Graph Sound Card idea

Hi Kuninori,

CC Jon

Some of my thoughts on below.

On 8/21/2020 9:45 AM, Kuninori Morimoto wrote:

External email: Use caution opening links or attachments

Hi Mark Cc Pierre-Louis, Sameer

Current audio-graph-card driver has DPCM support, but it is limited (= Mix/Mux/TDM-split/rate-convert/channel-convert). It was expanded forcibly expanded.

Yes it appears to be so. Right now it does not seem to be supporting 'demux' kind of use case.

Because of it, the connection judgement for normal vs DPCM is tricky.

Please note that asoc_simple_init_dai_link_params() makes the link codec-to-codec if any component involved has 'non_legacy_dai_naming' flag enabled. It is used by both audio-graph and simple-card. So it is a combination of three (DPCM, normal and codec-to-codec). To avoid all this complication, I am treating all links as DPCM in the series [0] I sent.

I know Pierre-Louis want to use it for SOF, but something is missing, thus, can't use (?).

I know now Sameer is currently trying to expand it now. It is OK for me, but, more expansion in the future will be difficult/buggy. For example supporting many *generic* DPCM and normal connection in the same time will be difficult.

If we encode use case information in DT, it would become regid and is not flexible when the HW is giving us the all flexibility (at least in my case). Thus may lead to complications. If there is a way to configure PCM parameters from the user space it would help to simplify things. Then DT can just describe the HW links.

I'm thinking below style as new audio-graph-card2. It is not tricky, thus connection judgement for normal vs DSP is easy. Then, code can be more readable (= no guaranty :P) ?

I guss "audio-graph-card" and "audio-graph-card2" can have some (= not full) compatible for normal connection. But has no compatible for DPCM connection.

I think I need to keep as-is for current audio-graph-card, and create new audio-graph-card2 driver. Because there is users, and card2 implementation will have huge different. Keeping compatible and update will be very difficult or buggy.

But what do you think ?

Note 1 is that this is just idea for now. I'm very happy to implement it, but it will be after that my all remaining patch was posted/accepted.

Note 2 is that I'm not full DPCM analyst. Thus, maybe audio-graph-card2 can solve current connection issue, but might can't for unknown connection case. In such came we need ver3 (?).

------------ image ---------------------------

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

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

PCM0 <------------> * * <----DAI0-----> Codec Headset * * PCM1 <------------> * * <----DAI1-----> Codec Speakers * DSP * PCM2 <------------> * * <----DAI2-----> MODEM * * PCM3 <------------> * * <----DAI3-----> BT * * * * <----DAI4-----> DMIC * * * * <----DAI5-----> FM ************* ------------ DT sample ---------------------------

     sound {
             compatible = "audio-graph-card2";

             dais = <&pcm0,
                     &pcm1,
                     &pcm2,
                     &pcm3>;
     };

     front-end {
             ports {
                     pcm0: port@0 { pcm0_endpoint: endpoint { remote-endpoint = <&dsp_f0>; }; };
                     pcm1: port@1 { pcm1_endpoint: endpoint { remote-endpoint = <&dsp_f1>; }; };
                     pcm2: port@2 { pcm2_endpoint: endpoint { remote-endpoint = <&dsp_f2>; }; };
                     pcm3: port@3 { pcm3_endpoint: endpoint { remote-endpoint = <&dsp_f3>; }; };
             };
     };

     dsp {
             compatible = "audio-graph-card2-dsp";

             ports {
                     /* Front End side */
                     port@0 { dsp_f0: endpoint { remote-endpoint = <&pcm0>; }; };
                     port@1 { dsp_f1: endpoint { remote-endpoint = <&pcm1>; }; };
                     port@2 { dsp_f2: endpoint { remote-endpoint = <&pcm2>; }; };
                     port@3 { dsp_f3: endpoint { remote-endpoint = <&pcm3>; }; };

                     /* Back End side */
                     port@4 { dsp_b0: endpoint { remote-endpoint = <&dai0>; }; };
                     port@5 { dsp_b1: endpoint { remote-endpoint = <&dai1>; }; };
                     port@6 { dsp_b2: endpoint { remote-endpoint = <&dai2>; }; };
                     port@7 { dsp_b3: endpoint { remote-endpoint = <&dai3>; }; };
                     port@8 { dsp_b4: endpoint { remote-endpoint = <&dai4>; }; };
                     port@9 { dsp_b5: endpoint { remote-endpoint = <&dai5>; }; };
             };
     };

     back-end {
             ports {
                     port@0 { dai0: endpoint { remote-endpoint = <&dsp_b0>; }; };
                     port@1 { dai1: endpoint { remote-endpoint = <&dsp_b1>; }; };
                     port@2 { dai2: endpoint { remote-endpoint = <&dsp_b2>; }; };
                     port@3 { dai3: endpoint { remote-endpoint = <&dsp_b3>; }; };
                     port@4 { dai4: endpoint { remote-endpoint = <&dsp_b4>; }; };
                     port@5 { dai5: endpoint { remote-endpoint = <&dsp_b5>; }; };
             };
     };

In my series [0], I am trying to achieve the similar as above though the description may look little different in my case, but that is what HW describes I believe.

[0] https://lkml.org/lkml/2020/8/5/42