alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
	Mark Brown <broonie@kernel.org>
Cc: Sameer Pujar <spujar@nvidia.com>,
	Linux-ALSA <alsa-devel@alsa-project.org>
Subject: Re: More Generic Audio Graph Sound Card idea
Date: Fri, 21 Aug 2020 10:49:53 -0500	[thread overview]
Message-ID: <8507bcc1-8b20-4d70-7fd2-1131f8b02d5b@linux.intel.com> (raw)
In-Reply-To: <87k0xszlep.wl-kuninori.morimoto.gx@renesas.com>

Hi Morimoto-san,

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

Here's a bit more background.

For SoundWire, we could have the following examples for amplifier 
connections, where in some cases we have two amplifiers located on 
separate links (top diagram) and in the second they are on the same link.

| FE PCMs    |  SoC DSP  | BE DAIs   | Audio devices |

              *************
   PCM0 <---> *           * DAI0 <---> Codec Headset
              *           *
   PCM1 <---> *           * DAI1 <---> Amp Left
              *   DSP     *
   PCM2 <---> *           * DAI2 <---> Amp Right
              *           *
   PCM3 <---> *           * DAI3 <---> BT
              *           *
              *           * DAI4 <---> DMIC
              *           *
              *           * DAI5 <---> FM
              *************

              *************
   PCM0 <---> *           * DAI0 <---> Codec Headset
              *           *
   PCM1 <---> *           * DAI1 <---> Amp Left
              *   DSP     *        |
   PCM2 <---> *           * DAI2/  --> Amp Right
              *           *
   PCM3 <---> *           * DAI3 <---> BT
              *           *
              *           * DAI4 <---> DMIC
              *           *
              *           * DAI5 <---> FM
              *************

We'd need a means to express that the two amplifiers are really supposed 
to operate concurrently and be synchronized, and let the drivers know 
which configuration to use (multi-cpu/multi-codec or single 
CPU/multi-codec).

Currently we do this manually by hard-coding an 'endpoint group', see 
e.g. 
https://elixir.bootlin.com/linux/latest/source/sound/soc/intel/common/soc-acpi-intel-cml-match.c#L69, 
and use this information in the machine driver to know which of the 
configurations to use.

At some point we'd like to read this information from platform firmware 
(will be ACPI for Intel but that's a detail) and create the dais in the 
right way by grouping endpoints on the same dailink when they are 
connected, and create separate dailink otherwise.

Note that we only want the connection between BEs and audio devices to 
be described in platform firmware, the topology inside the SOC DSP is 
handled with a topology file that can be changed at will to e.g. 
add/remove processing.

We really need to make sure the audio graph can be described in two 
parts, the bottom part related to hardware routing and layout, and the 
DSP part. Of course the topology part would have to be constrained to 
use the DAIs used in the lower level.

Hope this helps explain what I am looking for.

Thank you for starting this thread!

Regards

-Pierre

  parent reply	other threads:[~2020-08-21 15:51 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
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 [this message]
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=8507bcc1-8b20-4d70-7fd2-1131f8b02d5b@linux.intel.com \
    --to=pierre-louis.bossart@linux.intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=kuninori.morimoto.gx@renesas.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).