[alsa-devel] [PATCH v2] ASoC: dapm: Add new widget type for constructing DAPM graphs on DSPs.
Add some DAPM widget types to better support the construction of DAPM graphs within DSPs
Changes v1. o Added some documentation. o Split codec widget into encoder and decoder to avoid confusion with HW CODECS.
Signed-off-by: Liam Girdwood liam.r.girdwood@linux.intel.com --- Documentation/sound/soc/dapm.rst | 18 ++++++++++++++++++ include/sound/soc-dapm.h | 7 +++++++ include/uapi/sound/asoc.h | 10 +++++++++- sound/soc/soc-topology.c | 8 ++++++++ 4 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/Documentation/sound/soc/dapm.rst b/Documentation/sound/soc/dapm.rst index a27f42befa4d..78d63f6a35fa 100644 --- a/Documentation/sound/soc/dapm.rst +++ b/Documentation/sound/soc/dapm.rst @@ -105,6 +105,24 @@ Pre Special PRE widget (exec before all others) Post Special POST widget (exec after all others) +Buffer + Inter widget audio data buffer within a DSP. +Pipeline + Collection of widgets within a DSP, can represent a sequence of DSP + widgets and their collective configuration. +Effect + Widget that performs an audio processing effect. +SRC + Sample Rate Converter within DSP or CODEC +ASRC + Asynchronous Sample Rate Converter within DSP or CODEC +Encoder + Widget that encodes audio data from one format (usually PCM) to another + usually more compressed format. +Decoder + Widget that decodes audio data from a compressed format to an + uncompressed format like PCM. +
(Widgets are defined in include/sound/soc-dapm.h)
diff --git a/include/sound/soc-dapm.h b/include/sound/soc-dapm.h index a466f4bdc835..68fea6d97199 100644 --- a/include/sound/soc-dapm.h +++ b/include/sound/soc-dapm.h @@ -510,6 +510,13 @@ enum snd_soc_dapm_type { snd_soc_dapm_dai_out, snd_soc_dapm_dai_link, /* link between two DAI structures */ snd_soc_dapm_kcontrol, /* Auto-disabled kcontrol */ + snd_soc_dapm_buffer, /* DSP/CODEC internal buffer */ + snd_soc_dapm_pipeline, /* DSP/CODEC internal pipeline */ + snd_soc_dapm_effect, /* DSP/CODEC effect component */ + snd_soc_dapm_src, /* DSP/CODEC SRC component */ + snd_soc_dapm_asrc, /* DSP/CODEC ASRC component */ + snd_soc_dapm_encoder, /* FW/SW audio encoder component */ + snd_soc_dapm_decoder, /* FW/SW audio decoder component */ };
enum snd_soc_dapm_subclass { diff --git a/include/uapi/sound/asoc.h b/include/uapi/sound/asoc.h index 6702533c8bd8..8a4fdf3e7e2e 100644 --- a/include/uapi/sound/asoc.h +++ b/include/uapi/sound/asoc.h @@ -73,7 +73,15 @@ #define SND_SOC_TPLG_DAPM_DAI_IN 13 #define SND_SOC_TPLG_DAPM_DAI_OUT 14 #define SND_SOC_TPLG_DAPM_DAI_LINK 15 -#define SND_SOC_TPLG_DAPM_LAST SND_SOC_TPLG_DAPM_DAI_LINK +#define SND_SOC_TPLG_DAPM_BUFFER 16 +#define SND_SOC_TPLG_DAPM_PIPELINE 17 +#define SND_SOC_TPLG_DAPM_EFFECT 18 +#define SND_SOC_TPLG_DAPM_SIGGEN 19 +#define SND_SOC_TPLG_DAPM_SRC 20 +#define SND_SOC_TPLG_DAPM_ASRC 21 +#define SND_SOC_TPLG_DAPM_ENCODER 22 +#define SND_SOC_TPLG_DAPM_DECODER 23 +#define SND_SOC_TPLG_DAPM_LAST SND_SOC_TPLG_DAPM_DECODER
/* Header magic number and string sizes */ #define SND_SOC_TPLG_MAGIC 0x41536F43 /* ASoC */ diff --git a/sound/soc/soc-topology.c b/sound/soc/soc-topology.c index 12e189701924..b82d2755c2ac 100644 --- a/sound/soc/soc-topology.c +++ b/sound/soc/soc-topology.c @@ -242,6 +242,14 @@ static const struct soc_tplg_map dapm_map[] = { {SND_SOC_TPLG_DAPM_DAI_IN, snd_soc_dapm_dai_in}, {SND_SOC_TPLG_DAPM_DAI_OUT, snd_soc_dapm_dai_out}, {SND_SOC_TPLG_DAPM_DAI_LINK, snd_soc_dapm_dai_link}, + {SND_SOC_TPLG_DAPM_BUFFER, snd_soc_dapm_buffer}, + {SND_SOC_TPLG_DAPM_PIPELINE, snd_soc_dapm_pipeline}, + {SND_SOC_TPLG_DAPM_EFFECT, snd_soc_dapm_effect}, + {SND_SOC_TPLG_DAPM_SIGGEN, snd_soc_dapm_siggen}, + {SND_SOC_TPLG_DAPM_SRC, snd_soc_dapm_src}, + {SND_SOC_TPLG_DAPM_ASRC, snd_soc_dapm_asrc}, + {SND_SOC_TPLG_DAPM_ENCODER, snd_soc_dapm_encoder}, + {SND_SOC_TPLG_DAPM_DECODER, snd_soc_dapm_decoder}, };
static int tplc_chan_get_reg(struct soc_tplg *tplg,
On Fri, Jun 09, 2017 at 04:23:49PM +0100, Liam Girdwood wrote:
Changes v1. o Added some documentation. o Split codec widget into encoder and decoder to avoid confusion with HW CODECS.
Please put the inter-version changelogs after the --- so they get filtered out when applied.
+Pipeline
- Collection of widgets within a DSP, can represent a sequence of DSP
- widgets and their collective configuration.
+Effect
- Widget that performs an audio processing effect.
I'm still a bit unclear about how a pipeline and effect are different from an ASoC point of view - it matters on the DSP but from the kernel's point of view a pipeline just an effect that happens to have a more complicated implementation on the DSP?
On Fri, 2017-06-09 at 18:53 +0100, Mark Brown wrote:
On Fri, Jun 09, 2017 at 04:23:49PM +0100, Liam Girdwood wrote:
Changes v1. o Added some documentation. o Split codec widget into encoder and decoder to avoid confusion with HW CODECS.
Please put the inter-version changelogs after the --- so they get filtered out when applied.
+Pipeline
- Collection of widgets within a DSP, can represent a sequence of DSP
- widgets and their collective configuration.
+Effect
- Widget that performs an audio processing effect.
I'm still a bit unclear about how a pipeline and effect are different from an ASoC point of view - it matters on the DSP but from the kernel's point of view a pipeline just an effect that happens to have a more complicated implementation on the DSP?
Sorry for the delay.
Yes, that's true, some of the objects will most likely be treated the same by the kernel core but for the DSP and driver they will different. i.e. they create different objects with different topology private data (using the widget ID to differentiate).
Liam
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
On Wed, Jun 14, 2017 at 12:28:55PM +0100, Liam Girdwood wrote:
On Fri, 2017-06-09 at 18:53 +0100, Mark Brown wrote:
I'm still a bit unclear about how a pipeline and effect are different from an ASoC point of view - it matters on the DSP but from the kernel's point of view a pipeline just an effect that happens to have a more complicated implementation on the DSP?
Yes, that's true, some of the objects will most likely be treated the same by the kernel core but for the DSP and driver they will different. i.e. they create different objects with different topology private data (using the widget ID to differentiate).
Shouldn't that just be handled in the driver though? Nothing outside the driver cares. We're going to need to differentiate between different effects and pipelines in the driver anyway.
On Thu, 2017-06-15 at 11:01 +0100, Mark Brown wrote:
On Wed, Jun 14, 2017 at 12:28:55PM +0100, Liam Girdwood wrote:
On Fri, 2017-06-09 at 18:53 +0100, Mark Brown wrote:
I'm still a bit unclear about how a pipeline and effect are different from an ASoC point of view - it matters on the DSP but from the kernel's point of view a pipeline just an effect that happens to have a more complicated implementation on the DSP?
Yes, that's true, some of the objects will most likely be treated the same by the kernel core but for the DSP and driver they will different. i.e. they create different objects with different topology private data (using the widget ID to differentiate).
Shouldn't that just be handled in the driver though? Nothing outside the driver cares. We're going to need to differentiate between different effects and pipelines in the driver anyway.
It can be, just a little more code in the driver that's all. I'll remove the pipeline widget and resend.
Thanks
Liam
participants (2)
-
Liam Girdwood -
Mark Brown