From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
To: Sameer Pujar <spujar@nvidia.com>
Cc: Linux-ALSA <alsa-devel@alsa-project.org>,
Mark Brown <broonie@kernel.org>,
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
jonathanh@nvidia.com
Subject: Re: More Generic Audio Graph Sound Card idea
Date: 25 Sep 2020 10:43:59 +0900 [thread overview]
Message-ID: <87blhuljkb.wl-kuninori.morimoto.gx@renesas.com> (raw)
In-Reply-To: <87imdczd4i.wl-kuninori.morimoto.gx@renesas.com>
Hi
For more generic Auido Graph Sound Card, I'm thinking about
Multi-CPU/Codec now.
(Need to think about Codec-to-Codec later, but it is next task)
I want to know your idea, opinion, etc, etc...
> > 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.
>
> Ahh, we want to consider codec-to-codec..
> And I noticed multi-CPU / multi-Codec case too (= for normal connection).
> Do we have sample code ? > Mark
First idea is using "ports".
In such case, I think multi-CPU side is not big issue,
because "dais" selects "port" (and "ports") instead of "endpoint".
(Note: here have no compatible to "-scu-" of audio-graph)
CPU0-1 <------> Codec0
CPU0-2 <---/
CPU0-3 <---/
sound {
compatible = "audio-graph-card2";
=> dais = <&cpu0>;
};
cpu-device {
/*
* use "ports" for Multi-CPU
*/
=> cpu0: ports {
port@0 { cpu0_1: endpoint { remote-endpoint = <&codec0_1>; }; };
port@1 { cpu0_2: endpoint { remote-endpoint = <&codec0_2>; }; };
port@2 { cpu0_3: endpoint { remote-endpoint = <&codec0_3>; }; };
};
/*
* According to graph.txt,
* we can use other "port" and/or "ports" for non multi-CPU.
*/
port@x { };
port@x { };
ports {
port { };
...
};
};
codec-device {
port { codec0_1: endpoint@0 { remote-endpoint = <&cpu0_1>; };
codec0_2: endpoint@0 { remote-endpoint = <&cpu0_2>; };
codec0_3: endpoint@0 { remote-endpoint = <&cpu0_3>; }; };
};
But multi-Codec side is difficult.
Because it is selected via "endpoint" via CPU.
No way to select it via "port" and/or "ports".
CPU1 <------> Codec1-1
\---> Codec1-2
\---> Codec1-3
sound {
compatible = "audio-graph-card2";
dais = <&cpu1>;
};
cpu-device {
/*
* CPU selects Codec by "endpoints".
*/
cpu1: port { cpu1_1: endpoint { remote-endpoint = <&codec1_1>; };
cpu1_2: endpoint { remote-endpoint = <&codec1_2>; };
cpu1_3: endpoint { remote-endpoint = <&codec1_3>; };
};
};
codec-device {
/*
* Codec is selected via CPU.
* It is best if we can select "codec1" (= port / ports) from CPU.
* But is selected via "endpoint" in reality,
* using "ports" is not enough for Multi-Codec.
* because see below
*/
codec1: ports {
port@0 { codec1_1: endpoint { remote-endpoint = <&dai0_0>; }; };
port@1 { codec1_2: endpoint { remote-endpoint = <&dai0_1>; }; };
port@2 { codec1_3: endpoint { remote-endpoint = <&dai0_2>; }; };
};
/*
* Because "ports" is used to for non Multi-xxx too.
* How to know the "ports" was for Multi-xxx or not ?
*/
ports {
port@1 { for device1 };
port@2 { for device2 };
port@3 { for device3 };
};
};
We might want to select Multi-CPU/Codec by using multi deivces ?
in such case, using "ports" idea is not enough.
Using extra device like DSP can be more generic ?
<--- multi-CPU --->
*******
CPU0-1 <--> * * <--> Codec0
CPU0-2 <--> * *
CPU0-3 <--> * *
*******
sound {
compatible = "audio-graph-card2";
dais = <&cpu0>;
};
cpu-device {
ports {
/* for multi-CPU */
port@0 { cpu0_1: endpoint { remote-endpoint = <&multi_cpu_1>; }; };
port@1 { cpu0_2: endpoint { remote-endpoint = <&multi_cpu_2>; }; };
port@2 { cpu0_3: endpoint { remote-endpoint = <&multi_cpu_3>; }; };
/* for others */
port@3 { ... };
};
};
multi-cpu {
compatible = "audio-graph-card2-multi";
/* CPU side */
cpu0: ports@0 {
port@0 { multi_cpu_1: endpoint { remote-endpoint = <&cpu0_1>; }; };
port@1 { multi_cpu_2: endpoint { remote-endpoint = <&cpu0_2>; }; };
port@2 { multi_cpu_3: endpoint { remote-endpoint = <&cpu0_3>; }; };
};
/* Codec side */
ports@1 {
port@0 { multi_cpu0: endpoint { remote-endpoint = <&codec0>; }; };
};
};
codec-device {
ports {
port@0 { codec0: endpoint { remote-endpoint = <&multi_cpu0>; }; };
port@1 { ... };
};
};
<--- multi-Codec --->
*******
CPU1 <--> * * <--> Codec1-1
* * <--> Codec1-2
* * <--> Codec1-3
*******
sound {
compatible = "audio-graph-card2";
dais = <&cpu1>;
};
cpu-device {
ports {
cpu1: port@0 { cpu1_0: endpoint { remote-endpoint = <&multi_codec1>; }; };
port@1 { ... };
};
};
multi-cpu {
compatible = "audio-graph-card2-multi";
/* Front End */
ports@0 {
port { multi_codec1: endpoint { remote-endpoint = <&cpu1_0>; }; };
};
/* Back End */
ports@1 {
port@0 { multi_codec1_1: endpoint { remote-endpoint = <&codec1_1>; }; };
port@1 { multi_codec1_2: endpoint { remote-endpoint = <&codec1_2>; }; };
port@2 { multi_codec1_3: endpoint { remote-endpoint = <&codec1_3>; }; };
};
};
codec-device {
ports {
port@0 { codec1_1: endpoint { remote-endpoint = <&multi_codec1_1>; }; };
port@0 { codec1_2: endpoint { remote-endpoint = <&multi_codec1_2>; }; };
port@0 { codec1_3: endpoint { remote-endpoint = <&multi_codec1_3>; }; };
port@1 { ... };
};
};
Thank you for your help !!
Best regards
---
Kuninori Morimoto
next prev parent reply other threads:[~2020-09-25 1:45 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-21 4:15 More Generic Audio Graph Sound Card idea Kuninori Morimoto
2020-08-21 5:26 ` Sameer Pujar
2020-08-21 7:14 ` Kuninori Morimoto
2020-08-21 8:28 ` Sameer Pujar
2020-08-21 13:02 ` Mark Brown
2020-09-25 1:43 ` Kuninori Morimoto [this message]
2020-09-25 19:22 ` Mark Brown
2020-09-25 20:04 ` Pierre-Louis Bossart
2020-09-25 20:10 ` Mark Brown
2020-09-25 20:50 ` Pierre-Louis Bossart
2020-08-21 7:11 ` Daniel Baluta
2020-08-21 7:25 ` Kuninori Morimoto
2020-08-21 7:33 ` Daniel Baluta
2020-08-21 11:47 ` Mark Brown
2020-08-21 12:18 ` Mark Brown
2020-08-24 0:25 ` Kuninori Morimoto
2020-08-24 6:25 ` Sameer Pujar
2020-08-25 0:59 ` Kuninori Morimoto
2020-08-25 3:11 ` Sameer Pujar
2020-08-25 5:13 ` Kuninori Morimoto
2020-08-25 5:42 ` Sameer Pujar
2020-08-25 6:35 ` Kuninori Morimoto
2020-08-26 6:46 ` Sameer Pujar
2020-08-27 1:18 ` Kuninori Morimoto
2020-08-27 1:36 ` Kuninori Morimoto
2020-09-03 23:51 ` Kuninori Morimoto
2020-09-09 11:33 ` Sameer Pujar
2020-08-21 15:49 ` Pierre-Louis Bossart
2020-10-13 4:50 ` Kuninori Morimoto
2020-10-15 14:32 ` Mark Brown
2020-10-15 23:04 ` Kuninori Morimoto
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87blhuljkb.wl-kuninori.morimoto.gx@renesas.com \
--to=kuninori.morimoto.gx@renesas.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=jonathanh@nvidia.com \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=spujar@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).