asgardius/alsa-utils
1
0
Fork 0
mirror of https://github.com/alsa-project/alsa-utils synced 2025-01-03 18:49:47 +01:00
Code Issues Projects Releases Packages Wiki Activity
alsa-utils/topology/topology.h

40 lines
1.4 KiB
C
Raw Normal View History

topology: Add support for pre-processing Topology2.0 syntax This patch adds support for pre-processing the Topology2.0. The '-p' switch add pre-processing support during compilation and the '-P' switch is for converting the Topology2.0 configuration file into the existing syntax. Topology2.0 is a high level keyword extension on top of the existing ALSA conf topology format designed to: 1) Simplify the ALSA conf topology definitions by providing high level "classes" so topology designers need to write less config for common object definitions. 2) Allow simple reuse of objects. Define once and reuse (like M4) with the ability to alter objects configuration attributes from defaults. 3) Allow data type and value verification. This is not done today and frequently crops up in FW bug reports. Common Topology Classes ----------------------- Topology today has some common classes that are often reused throughout with slightly altered configurations. i.e. widgets (components), pipelines, dais and controls. Topology2.0 introduces the high level concept of reusable "class" like definition for that can be used to create topology objects. Common Topology Attributes -------------------------- Topology defines a lot of attributes per object with different types and constraints. Today there is no easy way to validate type or constraints and this can lead to many hard to find problems in FW at runtime. A new keyword "DefineAttribute" has been added to define attribute constraints such as min value, max value, enum_values etc. This then allows alsatplg to validate each topology object attribute. Topology Classes define the list of attributes that they use and whether the attribute is mandatory, can be overridden by parent users or is immutable. This also helps alsatplg emit the appropriate errors for attribute misuse. Class constructor attributes ---------------------------- Some attributes in the class definition are declared as constructor attributes and these will be used to construct the name of the object. For ex: for the host widget, the index and direction are constructor attributes and the name for the widget is derived as follows: host.1.playback or host.2.capture etc. Attribute Inheritance: ---------------------- One of the key features of Topology2.0 is how the attribute values are propagated from a parent object to a child object. For ex: a pipeline object can pass down the pipeline_id attribute to all its widgets. Inheritance is implicit when an object and its embedded child objects have matching names for a attribute/argument. Attribute values set explicitly in an object instance always has precedence over the values inherited from the parent object. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> 1 1 1 Signed-off-by: Jaroslav Kysela <perex@perex.cz>
2021-03-26 22:44:13 +01:00
/*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*/
#ifndef __TOPOLOGY_H
#define __TOPOLOGY_H
#include <stdlib.h>
/* pre_processor */
struct tplg_pre_processor {
snd_config_t *input_cfg;
snd_config_t *output_cfg;
snd_output_t *output;
snd_output_t *dbg_output;
topology: pre-processor: Move the call to expand variables Remove the call to snd_config_expand_custom() to expand the top-level input config. And replace it with calls to snd_config_evaluate_string() for each non-compound config while processing individual objects. This will allow retreving variable definitions from object attribute values and global definitions. Add a new field "current_obj_cfg" to hold the current object config being pre-processed. This will facilitate adding simple math expressions for computing attribute values for objects based on other attributes. For ex: we can set the expression for buffer size as follows: buffer_size "$[($in_channels * 48) * 4]" The buffer_size attribute value will be computed with the attribute value "in_channels" based on the expression above. So if $in_channels = 2, buffer_size will be evaluated to 384. Additionally this change also permits computing attribute values based on previously computed values. For example: buffer_size "$[($in_channels * 48) * 4]" dma_buffer_size "$[$buffer_size * 2]" dma_buffer_size will be computed as 768. Note that the order of definitions for buffer_size and dma_buffer_size matters because the evaluation for dma_buffer_size depends on the evaluation of buffer_size. In order to conform to this, the tplg_object_copy_and_add_param() is modified to add attribute configs from class config to an object using snd_config_before() instead of snd_config_add(). With this change, we no longer need to set the auto_attr_updater for buffer type widget objects. So remove it. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Jaroslav Kysela <perex@perex.cz>
2021-12-11 19:45:43 +01:00
snd_config_t *current_obj_cfg;
topology: optimization for pre_processor_defs parsing Parse the configuration tree only one time and then reuse it for the merge. Also, do not pass inc_path to all functions - add it to the pre-processor structure. Signed-off-by: Jaroslav Kysela <perex@perex.cz>
2022-01-27 14:58:55 +01:00
snd_config_t *define_cfg;
snd_config_t *define_cfg_merged;
char *inc_path;
topology: Add support for pre-processing Topology2.0 syntax This patch adds support for pre-processing the Topology2.0. The '-p' switch add pre-processing support during compilation and the '-P' switch is for converting the Topology2.0 configuration file into the existing syntax. Topology2.0 is a high level keyword extension on top of the existing ALSA conf topology format designed to: 1) Simplify the ALSA conf topology definitions by providing high level "classes" so topology designers need to write less config for common object definitions. 2) Allow simple reuse of objects. Define once and reuse (like M4) with the ability to alter objects configuration attributes from defaults. 3) Allow data type and value verification. This is not done today and frequently crops up in FW bug reports. Common Topology Classes ----------------------- Topology today has some common classes that are often reused throughout with slightly altered configurations. i.e. widgets (components), pipelines, dais and controls. Topology2.0 introduces the high level concept of reusable "class" like definition for that can be used to create topology objects. Common Topology Attributes -------------------------- Topology defines a lot of attributes per object with different types and constraints. Today there is no easy way to validate type or constraints and this can lead to many hard to find problems in FW at runtime. A new keyword "DefineAttribute" has been added to define attribute constraints such as min value, max value, enum_values etc. This then allows alsatplg to validate each topology object attribute. Topology Classes define the list of attributes that they use and whether the attribute is mandatory, can be overridden by parent users or is immutable. This also helps alsatplg emit the appropriate errors for attribute misuse. Class constructor attributes ---------------------------- Some attributes in the class definition are declared as constructor attributes and these will be used to construct the name of the object. For ex: for the host widget, the index and direction are constructor attributes and the name for the widget is derived as follows: host.1.playback or host.2.capture etc. Attribute Inheritance: ---------------------- One of the key features of Topology2.0 is how the attribute values are propagated from a parent object to a child object. For ex: a pipeline object can pass down the pipeline_id attribute to all its widgets. Inheritance is implicit when an object and its embedded child objects have matching names for a attribute/argument. Attribute values set explicitly in an object instance always has precedence over the values inherited from the parent object. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> 1 1 1 Signed-off-by: Jaroslav Kysela <perex@perex.cz>
2021-03-26 22:44:13 +01:00
};
topology: Add option to pass pre-processor definitions Add a -D switch to be able to pass pre-processor definitions that will be used to expand arguments in the input config file. This will be useful to generate multiple topology binaries from the same input config file with different argument values. For example: if we had a pipeline config as follows: Object.Pipeline { volume-playback.1 { dynamic_pipeline $DYNAMIC_PIPELINE } } We can define the variable for DYNAMIC_PIPELINE as: Define { DYNAMIC_PIPELINE 0 } And when pre-processing the conf file pass "-D DYNAMIC_PIPELINE=1" to override the default value for dynamic_pipeline attribute in the input conf file. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Jaroslav Kysela <perex@perex.cz>
2021-11-04 20:17:24 +01:00
int pre_process(struct tplg_pre_processor *tplg_pp, char *config, size_t config_size,
topology: change include path Add support for relative (based on the path from the parsed configuration file) and absolute include path without ALSA_CONFIG_DIR environment variable usage. The dependency on the alsa-lib config tree may be added on demand. Link: https://github.com/alsa-project/alsa-utils/pull/117 Link: https://github.com/alsa-project/alsa-utils/issues/118 Signed-off-by: Jaroslav Kysela <perex@perex.cz>
2021-12-06 10:13:22 +01:00
const char *pre_processor_defs, const char *inc_path);
int init_pre_processor(struct tplg_pre_processor **tplg_pp, snd_output_type_t type,
topology: Add support for pre-processing Topology2.0 syntax This patch adds support for pre-processing the Topology2.0. The '-p' switch add pre-processing support during compilation and the '-P' switch is for converting the Topology2.0 configuration file into the existing syntax. Topology2.0 is a high level keyword extension on top of the existing ALSA conf topology format designed to: 1) Simplify the ALSA conf topology definitions by providing high level "classes" so topology designers need to write less config for common object definitions. 2) Allow simple reuse of objects. Define once and reuse (like M4) with the ability to alter objects configuration attributes from defaults. 3) Allow data type and value verification. This is not done today and frequently crops up in FW bug reports. Common Topology Classes ----------------------- Topology today has some common classes that are often reused throughout with slightly altered configurations. i.e. widgets (components), pipelines, dais and controls. Topology2.0 introduces the high level concept of reusable "class" like definition for that can be used to create topology objects. Common Topology Attributes -------------------------- Topology defines a lot of attributes per object with different types and constraints. Today there is no easy way to validate type or constraints and this can lead to many hard to find problems in FW at runtime. A new keyword "DefineAttribute" has been added to define attribute constraints such as min value, max value, enum_values etc. This then allows alsatplg to validate each topology object attribute. Topology Classes define the list of attributes that they use and whether the attribute is mandatory, can be overridden by parent users or is immutable. This also helps alsatplg emit the appropriate errors for attribute misuse. Class constructor attributes ---------------------------- Some attributes in the class definition are declared as constructor attributes and these will be used to construct the name of the object. For ex: for the host widget, the index and direction are constructor attributes and the name for the widget is derived as follows: host.1.playback or host.2.capture etc. Attribute Inheritance: ---------------------- One of the key features of Topology2.0 is how the attribute values are propagated from a parent object to a child object. For ex: a pipeline object can pass down the pipeline_id attribute to all its widgets. Inheritance is implicit when an object and its embedded child objects have matching names for a attribute/argument. Attribute values set explicitly in an object instance always has precedence over the values inherited from the parent object. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> 1 1 1 Signed-off-by: Jaroslav Kysela <perex@perex.cz>
2021-03-26 22:44:13 +01:00
const char *output_file);
topology: rename function free_pre_preprocessor to free_pre_processor Line up this name with others. Signed-off-by: Jaroslav Kysela <perex@perex.cz>
2022-01-27 15:01:50 +01:00
void free_pre_processor(struct tplg_pre_processor *tplg_pp);
topology: Add support for pre-processing Topology2.0 syntax This patch adds support for pre-processing the Topology2.0. The '-p' switch add pre-processing support during compilation and the '-P' switch is for converting the Topology2.0 configuration file into the existing syntax. Topology2.0 is a high level keyword extension on top of the existing ALSA conf topology format designed to: 1) Simplify the ALSA conf topology definitions by providing high level "classes" so topology designers need to write less config for common object definitions. 2) Allow simple reuse of objects. Define once and reuse (like M4) with the ability to alter objects configuration attributes from defaults. 3) Allow data type and value verification. This is not done today and frequently crops up in FW bug reports. Common Topology Classes ----------------------- Topology today has some common classes that are often reused throughout with slightly altered configurations. i.e. widgets (components), pipelines, dais and controls. Topology2.0 introduces the high level concept of reusable "class" like definition for that can be used to create topology objects. Common Topology Attributes -------------------------- Topology defines a lot of attributes per object with different types and constraints. Today there is no easy way to validate type or constraints and this can lead to many hard to find problems in FW at runtime. A new keyword "DefineAttribute" has been added to define attribute constraints such as min value, max value, enum_values etc. This then allows alsatplg to validate each topology object attribute. Topology Classes define the list of attributes that they use and whether the attribute is mandatory, can be overridden by parent users or is immutable. This also helps alsatplg emit the appropriate errors for attribute misuse. Class constructor attributes ---------------------------- Some attributes in the class definition are declared as constructor attributes and these will be used to construct the name of the object. For ex: for the host widget, the index and direction are constructor attributes and the name for the widget is derived as follows: host.1.playback or host.2.capture etc. Attribute Inheritance: ---------------------- One of the key features of Topology2.0 is how the attribute values are propagated from a parent object to a child object. For ex: a pipeline object can pass down the pipeline_id attribute to all its widgets. Inheritance is implicit when an object and its embedded child objects have matching names for a attribute/argument. Attribute values set explicitly in an object instance always has precedence over the values inherited from the parent object. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> 1 1 1 Signed-off-by: Jaroslav Kysela <perex@perex.cz>
2021-03-26 22:44:13 +01:00
#endif
Reference in a new issue Copy permalink