alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
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

  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).