Data Structures
struct	snd_tplg_tlv_template
	Template type for all TLV objects. More...
struct	snd_tplg_tlv_dbscale_template
	Template type for TLV Scale objects. More...
struct	snd_tplg_channel_elem
	Template type for single channel mapping. More...
struct	snd_tplg_channel_map_template
	Template type for channel mapping. More...
struct	snd_tplg_pdata_template
	Template type for private data objects. More...
struct	snd_tplg_io_ops_template
	Template type for object operations mapping. More...
struct	snd_tplg_ctl_template
	Template type for control objects. More...
struct	snd_tplg_mixer_template
	Template type for mixer control objects. More...
struct	snd_tplg_enum_template
	Template type for enumerated control objects. More...
struct	snd_tplg_bytes_template
	Template type for TLV Scale objects. More...
struct	snd_tplg_graph_elem
	Template type for single DAPM graph element. More...
struct	snd_tplg_graph_template
	Template type for array of DAPM graph elements. More...
struct	snd_tplg_widget_template
	Template type for DAPM widget objects. More...
struct	snd_tplg_stream_template
	Stream configurations. More...
struct	snd_tplg_stream_caps_template
	Stream Capabilities. More...
struct	snd_tplg_pcm_template
	Template type for PCM (FE DAI & DAI links). More...
struct	snd_tplg_hw_config_template
	Template type to describe a physical link runtime supported hardware config, i.e. hardware audio formats. More...
struct	snd_tplg_dai_template
	Template type for physical DAI. It can be used to configure backend DAIs for DPCM. More...
struct	snd_tplg_link_template
	Template type for physical DAI Links. More...
struct	snd_tplg_obj_template_t
	Generic Template Object. More...

Macros
#define	SND_TPLG_MAX_CHAN 8
#define	SND_TPLG_INDEX_ALL 0
#define	SND_TPLG_CREATE_VERBOSE (1<<0)
#define	SND_TPLG_CREATE_DAPM_NOSORT (1<<1)
#define	SND_TPLG_SAVE_SORT (1<<0)
#define	SND_TPLG_SAVE_GROUPS (1<<1)
#define	SND_TPLG_SAVE_NOCHECK (1<<16)

Typedefs
typedef struct snd_tplg	snd_tplg_t

Functions
const char *	snd_tplg_version (void)
	Return the version of the topology library.
snd_tplg_t *	snd_tplg_new (void)
	Create a new topology parser instance.
snd_tplg_t *	snd_tplg_create (int flags)
	Create a new topology parser instance.
void	snd_tplg_free (snd_tplg_t *tplg)
	Free a topology parser instance.
int	snd_tplg_load (snd_tplg_t tplg, const char buf, size_t size)
	Load topology from the text buffer.
int	snd_tplg_build_file (snd_tplg_t tplg, const char infile, const char *outfile)
	Parse and build topology text file into binary file.
void	snd_tplg_verbose (snd_tplg_t *tplg, int verbose)
	Enable verbose reporting of binary file output.
int	snd_tplg_add_object (snd_tplg_t tplg, snd_tplg_obj_template_t t)
	Register topology template object.
int	snd_tplg_build (snd_tplg_t tplg, const char outfile)
	Build all registered topology data into binary file.
int	snd_tplg_build_bin (snd_tplg_t tplg, void bin, size_t size)
	Build all registered topology data into memory.
int	snd_tplg_set_manifest_data (snd_tplg_t tplg, const void data, int len)
	Attach private data to topology manifest.
int	snd_tplg_set_version (snd_tplg_t *tplg, unsigned int version)
	Set an optional vendor specific version number.
int	snd_tplg_save (snd_tplg_t tplg, char *dst, int flags)
	Save the topology to the text configuration string.
int	snd_tplg_decode (snd_tplg_t tplg, void bin, size_t size, int dflags)
	Decode the binary topology contents.

Detailed Description

ALSA Topology Interface

The topology interface allows developers to define DSP topologies in a text file format and to convert the text topology to a binary topology representation that can be understood by the kernel. The topology core currently recognises the following object types :-

Controls (mixer, enumerated and byte) including TLV data.
PCMs (Front End DAI & DAI link)
DAPM widgets
DAPM graph elements.
Physical DAI & DAI links
Private data for each object type.
Manifest (containing count of each object type)

Topology File Format

The topology text format uses the standard ALSA configuration file format to describe each topology object type. This allows topology objects to include other topology objects as part of their definition. i.e. a TLV data object can be shared amongst many control objects that use the same TLV data.

Controls

Topology audio controls can belong to three different types :-

Mixer control
Enumerated control
Byte control

Each control type can contain TLV data, private data, operations and also belong to widget objects.

Control Operations

Driver Kcontrol callback info(), get() and put() operations are mapped with the CTL ops section in topology configuration files. The ctl ops section can assign operations using the standard names (listed below) for the standard kcontrol types or use ID numbers (>256) to map to bespoke driver controls.


    ops."ctl" {
        info "volsw"
        get "257"
        put "257"
    }

This mapping shows info() using the standard "volsw" info callback whilst the get() and put() are mapped to bespoke driver callbacks.

The Standard operations names for control get(), put() and info calls are :-

volsw
volsw_sx
volsw_xr_sx
enum
bytes
enum_value
range
strobe

Control Access

Controls access can be specified using the "access" section. If no "access" section is defined then default RW access flags are set for normal and TLV controls.

    access [
        read
        write
        tlv_command
    ]

The standard access flags are as follows :-

read
write
read_write
volatile
timestamp
tlv_read
tlv_write
tlv_read_write
tlv_command
inactive
lock
owner
tlv_callback
user

Control TLV Data

Controls can also use TLV data to represent dB information. This can be done by defining a TLV section and using the TLV section within the control. The TLV data for DBScale types are defined as follows :-

    scale {
        min "-9000"
        step "300"
        mute "1"
    }

Where the meanings and values for min, step and mute are exactly the same as defined in driver code.

Control Channel Mapping

Controls can also specify which channels they are mapped with. This is useful for userspace as it allows applications to determine the correct control channel for Left and Right etc. Channel maps are defined as follows :-

    channel."name" {
        reg "0"
        shift "0"
    }

The channel map reg is the register offset for the control, shift is the bit shift within the register for the channel and the section name is the channel name and can be one of the following :-

  * mono        # mono stream
  * fl      # front left
  * fr      # front right
  * rl      # rear left
  * rr      # rear right
  * fc      # front center
  * lfe     # LFE
  * sl      # side left
  * sr      # side right
  * rc      # rear center
  * flc     # front left center
  * frc     # front right center
  * rlc     # rear left center
  * rrc     # rear right center
  * flw     # front left wide
  * frw     # front right wide
  * flh     # front left high
  * fch     # front center high
  * frh     # front right high
  * tc      # top center
  * tfl     # top front left
  * tfr     # top front right
  * tfc     # top front center
  * trl     # top rear left
  * trr     # top rear right
  * trc     # top rear center
  * tflc        # top front left center
  * tfrc        # top front right center
  * tsl     # top side left
  * tsr     # top side right
  * llfe        # left LFE
  * rlfe        # right LFE
  * bc      # bottom center
  * blc     # bottom left center
  * brc     # bottom right center

Control Private Data

Controls can also have private data. This can be done by defining a private data section and including the section within the control. The private data section is defined as follows :-

 SectionData."pdata for EQU1" {
    file "/path/to/file"
    bytes "0x12,0x34,0x56,0x78"
    shorts "0x1122,0x3344,0x5566,0x7788"
    words "0xaabbccdd,0x11223344,0x66aa77bb,0xefef1234"
    tuples "section id of the vendor tuples"
 };

The file, bytes, shorts, words and tuples keywords are all mutually exclusive as the private data should only be taken from one source. The private data can either be read from a separate file or defined in the topology file using the bytes, shorts, words or tuples keywords. The keyword tuples is to define vendor specific tuples. Please refer to section Vendor Tokens and Vendor tuples.

It's easy to use a vendor tuples object to define a C structure instance. And a data section can include multiple vendor tuples objects:

 SectionData."data element name" {
    index "1"   # Index number
    tuples [
        "id of the 1st vendor tuples section"
        "id of the 2nd vendor tuples section"
        ...
    ]
 };

How to define an element with private data

An element can refer to a single data section or multiple data sections.

To refer to a single data section:

 Sectionxxx."element name" {
    ...
    data "name of data section"     # optional private data
 }

To refer to multiple data sections:

 Sectionxxx."element name" {
    ...
    data [                      # optional private data
        "name of 1st data section"
        "name of 2nd data section"
        ...
    ]
 }

And data of these sections will be merged in the same order as they are in the list, as the element's private data for kernel.

Vendor Tokens

A vendor token list is defined as a new section. Each token element is a pair of string ID and integer value. And both the ID and value are vendor-specific.

 SectionVendorTokens."id of the vendor tokens" {
    comment "optional comments"
    VENDOR_TOKEN_ID1 "1"
    VENDOR_TOKEN_ID2 "2"
    VENDOR_TOKEN_ID3 "3"
    ...
 }

Vendor Tuples

Vendor tuples are defined as a new section. It contains a reference to a vendor token list and several tuple arrays. All arrays share a vendor token list, defined by the tokens keyword. Each tuple array is for a specific type, defined by the string following the tuples keyword. Supported types are: string, uuid, bool, byte, short and word.

 SectionVendorTuples."id of the vendor tuples" {
    tokens "id of the vendor tokens"

    tuples."string" {
        VENDOR_TOKEN_ID1 "character string"
        ...
    }

    tuples."uuid" {         # 16 characters separated by commas
        VENDOR_TOKEN_ID2 "0x01,0x02,...,0x0f"
        ...
    }

    tuples."bool" {
        VENDOR_TOKEN_ID3 "true/false"
        ...
    }

    tuples."byte" {
        VENDOR_TOKEN_ID4 "0x11"
        VENDOR_TOKEN_ID5 "0x22"
        ...
    }

    tuples."short" {
        VENDOR_TOKEN_ID6 "0x1122"
        VENDOR_TOKEN_ID7 "0x3344"
        ...
    }

    tuples."word" {
        VENDOR_TOKEN_ID8 "0x11223344"
        VENDOR_TOKEN_ID9 "0x55667788"
        ...
    }
 }

To define multiple vendor tuples of same type, please append some characters after the type string ("string", "uuid", "bool", "byte", "short" or "word"), to avoid ID duplication in the SectionVendorTuples.
The parser will check the first few characters in ID to get the tuple type. Here is an example:

 SectionVendorTuples."id of the vendor tuples" {
    ...
    tuples."word.module0" {
        VENDOR_TOKEN_PARAM_ID1 "0x00112233"
        VENDOR_TOKEN_PARAM_ID2 "0x44556677"
        ...
    }

    tuples."word.module2" {
        VENDOR_TOKEN_PARAM_ID1 "0x11223344"
        VENDOR_TOKEN_PARAM_ID2 "0x55667788"
        ...
    }
    ...
 }

Mixer Controls

A mixer control is defined as a new section that can include channel mapping, TLV data, callback operations and private data. The mixer section also includes a few other config options that are shown here :-

 SectionControlMixer."mixer name" {
    comment "optional comments"

    index "1"           # Index number

    channel."name" {        # Channel maps
       ....
    }

    ops."ctl" {         # Ops callback functions
       ....
    }

    max "32"            # Max control value
    invert "0"          # Whether control values are inverted

    tlv "tld_data"          # optional TLV data

    data "pdata for mixer1"     # optional private data
 }

The section name is used to define the mixer name. The index number can be used to identify topology objects groups(index "0" is common, fit for all user cases).This allows driver operations on objects with index number N and can be used to add/remove pipelines of objects whilst other objects are unaffected.

Byte Controls

A byte control is defined as a new section that can include channel mapping, TLV data, callback operations and private data. The bytes section also includes a few other config options that are shown here :-

 SectionControlBytes."name" {
    comment "optional comments"

    index "1"           # Index number

    channel."name" {        # Channel maps
       ....
    }

    ops."ctl" {         # Ops callback functions
       ....
    }

    base "0"            # Register base
    num_regs "16"           # Number of registers
    mask "0xff"         # Mask
    max "255"           # Maximum value

    tlv "tld_data"          # optional TLV data

    data "pdata for mixer1"     # optional private data
 }

Enumerated Controls

A enumerated control is defined as a new section (like mixer and byte) that can include channel mapping, callback operations, private data and text strings to represent the enumerated control options.

The text strings for the enumerated controls are defined in a separate section as follows :-

 SectionText."name" {

        Values [
            "value1"
            "value2"
            "value3"
        ]
 }

All the enumerated text values are listed in the values list.
The enumerated control is similar to the other controls and defined as follows :-

 SectionControlMixer."name" {
    comment "optional comments"

    index "1"           # Index number

    texts "EQU1"            # Enumerated text items

    channel."name" {        # Channel maps
       ....
    }

    ops."ctl" {         # Ops callback functions
       ....
    }

    data "pdata for mixer1"     # optional private data
 }

DAPM Graph

DAPM graphs can easily be defined using the topology file. The format is very similar to the DAPM graph kernel format. :-

 SectionGraph."dsp" {
    index "1"           # Index number

    lines [
        "sink1, control, source1"
        "sink2, , source2"
    ]
 }

The lines in the graph are defined as a variable size list of sinks, controls and sources. The control name is optional as some graph lines have no associated controls. The section name can be used to differentiate the graph with other graphs, it's not used by the kernel atm.

DAPM Widgets

DAPM widgets are similar to controls in that they can include many other objects. Widgets can contain private data, mixer controls and enum controls.

The following widget types are supported and match the driver types :-

input
output
mux
mixer
pga
out_drv
adc
dac
switch
pre
post
aif_in
aif_out
dai_in
dai_out
dai_link

Widgets are defined as follows :-

 SectionWidget."name" {

    index "1"           # Index number

    type "aif_in"           # Widget type - detailed above
    stream_name "name"      # Stream name

    no_pm "true"            # No PM control bit.
    reg "20"            # PM bit register offset
    shift "0"           # PM bit register shift
    invert "1"          # PM bit is inverted
    subseq "8"          # subsequence number

    event_type "1"          # DAPM widget event type
    event_flags "1"         # DAPM widget event flags

    mixer "name"            # Optional Mixer Control
    enum "name"         # Optional Enum Control

    data "name"         # optional private data
 }

The section name is the widget name. The mixer and enum fields are mutually exclusive and used to include controls into the widget. The index and data fields are the same for widgets as they are for controls whilst the other fields map on very closely to the driver widget fields.

Widget Private Data

Widget can have private data. For the format of the private data, please refer to section Control Private Data.

PCM Capabilities

Topology can also define the PCM capabilities of front end or physical DAIs. Capabilities can be defined with the following section :-

 SectionPCMCapabilities."name" {

    formats "S24_LE,S16_LE"     # Supported formats
    rates "48000"           # Supported rates
    rate_min "48000"        # Max supported sample rate
    rate_max "48000"        # Min supported sample rate
    channels_min "2"        # Min number of channels
    channels_max "2"        # max number of channels
 }

The supported formats use the same naming convention as the driver macros. The PCM capabilities name can be referred to and included by PCM and physical DAI sections.

PCM Configurations

PCM runtime configurations can be defined for playback and capture stream directions with the following section :-

 SectionPCMConfig."name" {

    config."playback" {     # playback config
        format "S16_LE"     # playback format
        rate "48000"        # playback sample rate
        channels "2"        # playback channels
        tdm_slot "0xf"      # playback TDM slot
    }

    config."capture" {      # capture config
        format "S16_LE"     # capture format
        rate "48000"        # capture sample rate
        channels "2"        # capture channels
        tdm_slot "0xf"      # capture TDM slot
    }
 }

The supported formats use the same naming convention as the driver macros. The PCM configuration name can be referred to and included by PCM and physical link sections.

PCM (Front-end DAI & DAI link)

PCM sections define the supported capabilities and configurations for supported playback and capture streams, names and flags for front end DAI & DAI links. Topology kernel driver will use a PCM object to create a pair of FE DAI & DAI links.

 SectionPCM."name" {

    index "1"           # Index number

    id "0"              # used for binding to the PCM

    dai."name of front-end DAI" {
        id "0"      # used for binding to the front-end DAI
    }

    pcm."playback" {
        capabilities "capabilities1"    # capabilities for playback

        configs [       # supported configs for playback
            "config1"
            "config2"
        ]
    }

    pcm."capture" {
        capabilities "capabilities2"    # capabilities for capture

        configs [       # supported configs for capture
            "config1"
            "config2"
            "config3"
        ]
    }

    # Optional boolean flags
    symmetric_rates         "true"
    symmetric_channels      "true"
    symmetric_sample_bits       "false"

    data "name"         # optional private data
 }

Physical DAI Link Configurations

The runtime configurations of a physical DAI link can be defined by SectionLink.
Backend DAI links belong to physical links, and can be configured by either SectionLink or SectionBE, with same syntax. But SectionBE is deprecated atm since the internal processing is actually same.

 SectionLink."name" {

    index "1"           # Index number

    id "0"              # used for binding to the link

    stream_name "name"      # used for binding to the link

    hw_configs [    # runtime supported HW configurations, optional
        "config1"
        "config2"
        ...
    ]

    default_hw_conf_id "1"      # default HW config ID for init

    # Optional boolean flags
    symmetric_rates         "true"
    symmetric_channels      "false"
    symmetric_sample_bits       "true"

    data "name"         # optional private data
 }

A physical link can refer to multiple runtime supported hardware configurations, which is defined by SectionHWConfig.

 SectionHWConfig."name" {

    id "1"              # used for binding to the config
    format "I2S"            # physical audio format.
    bclk   "codec_provider"     # Codec provides the bit clock
    fsync  "codec_consumer"     # Codec follows the fsync
 }

Physical DAI

A physical DAI (e.g. backend DAI for DPCM) is defined as a new section that can include a unique ID, playback and capture stream capabilities, optional flags, and private data.
Its PCM stream capablities are same as those for PCM objects, please refer to section 'PCM Capabilities'.

 SectionDAI."name" {

    index "1"           # Index number

    id "0"              # used for binding to the Backend DAI

    pcm."playback" {
        capabilities "capabilities1"    # capabilities for playback
    }

    pcm."capture" {
        capabilities "capabilities2"    # capabilities for capture
    }

    symmetric_rates "true"          # optional flags
    symmetric_channels "true"
    symmetric_sample_bits "false"

    data "name"         # optional private data
 }

Manifest Private Data

Manfiest may have private data. Users need to define a manifest section and add the references to 1 or multiple data sections. Please refer to section 'How to define an element with private data'.
And the text conf file can have at most 1 manifest section.

Manifest section is defined as follows :-

 SectionManifest"name" {

    data "name"         # optional private data
 }

Include other files

Users may include other files in a text conf file via alsaconf syntax <path/to/configuration-file>. This allows users to define common info in separate files (e.g. vendor tokens, tuples) and share them for different platforms, thus save the total size of config files.
Users can also specifiy additional configuraiton directories relative to "/usr/share/alsa/" to search the included files, via alsaconf syntax <searchfdir:/relative-path/to/usr/share/alsa>.

For example, file A and file B are two text conf files for platform X, they will be installed to /usr/share/alsa/topology/platformx. If we need file A to include file B, in file A we can add:

<searchdir:topology/platformx>
<name-of-file-B>

ALSA conf will search and open an included file in the following order of priority:

directly open the file by its name;
search for the file name in "/usr/share/alsa";
search for the file name in user specified subdirectories under "/usr/share/alsa".

The order of the included files need not to be same as their dependencies, since the topology library will load them all before parsing their dependencies.

The configuration directories defined by a file will only be used to search the files included by this file.

Macro Definition Documentation

◆ SND_TPLG_CREATE_DAPM_NOSORT

#define SND_TPLG_CREATE_DAPM_NOSORT (1<<1)

Do not sort DAPM objects by index

◆ SND_TPLG_CREATE_VERBOSE

#define SND_TPLG_CREATE_VERBOSE (1<<0)

Flags for the snd_tplg_create Verbose output

◆ SND_TPLG_INDEX_ALL

#define SND_TPLG_INDEX_ALL 0

Fit for all user cases

◆ SND_TPLG_MAX_CHAN

#define SND_TPLG_MAX_CHAN 8

Maximum number of channels supported in one control

◆ SND_TPLG_SAVE_GROUPS

#define SND_TPLG_SAVE_GROUPS (1<<1)

create the structure by group index

◆ SND_TPLG_SAVE_NOCHECK

#define SND_TPLG_SAVE_NOCHECK (1<<16)

unchecked output for debugging

◆ SND_TPLG_SAVE_SORT

#define SND_TPLG_SAVE_SORT (1<<0)

sort identifiers

Typedef Documentation

◆ snd_tplg_t

typedef struct snd_tplg snd_tplg_t

Topology context

Enumeration Type Documentation

◆ snd_tplg_type

enum snd_tplg_type

Topology object types

Enumerator
SND_TPLG_TYPE_TLV	TLV Data
SND_TPLG_TYPE_MIXER	Mixer control
SND_TPLG_TYPE_ENUM	Enumerated control
SND_TPLG_TYPE_TEXT	Text data
SND_TPLG_TYPE_DATA	Private data
SND_TPLG_TYPE_BYTES	Byte control
SND_TPLG_TYPE_STREAM_CONFIG	PCM Stream configuration
SND_TPLG_TYPE_STREAM_CAPS	PCM Stream capabilities
SND_TPLG_TYPE_PCM	PCM stream device
SND_TPLG_TYPE_DAPM_WIDGET	DAPM widget
SND_TPLG_TYPE_DAPM_GRAPH	DAPM graph elements
SND_TPLG_TYPE_BE	BE DAI link
SND_TPLG_TYPE_CC	Hostless codec <-> codec link
SND_TPLG_TYPE_MANIFEST	Topology manifest
SND_TPLG_TYPE_TOKEN	Vendor tokens
SND_TPLG_TYPE_TUPLE	Vendor tuples
SND_TPLG_TYPE_LINK	Physical DAI link
SND_TPLG_TYPE_HW_CONFIG	Link HW config
SND_TPLG_TYPE_DAI	Physical DAI

Function Documentation

◆ snd_tplg_add_object()

int snd_tplg_add_object	(	snd_tplg_t *	tplg,
		snd_tplg_obj_template_t *	t )

Register topology template object.

Parameters

tplg	Topology instance.
t	Template object.

Returns: Zero on success, otherwise a negative error code

◆ snd_tplg_build()

int snd_tplg_build	(	snd_tplg_t *	tplg,
		const char *	outfile )

Build all registered topology data into binary file.

Parameters

tplg	Topology instance.
outfile	Binary topology output file.

Returns: Zero on success, otherwise a negative error code

◆ snd_tplg_build_bin()

int snd_tplg_build_bin	(	snd_tplg_t *	tplg,
		void **	bin,
		size_t *	size )

Build all registered topology data into memory.

Parameters

tplg	Topology instance.
bin	Binary topology output buffer (malloc).
size	Binary topology output buffer size in bytes.

Returns: Zero on success, otherwise a negative error code

◆ snd_tplg_build_file()

int snd_tplg_build_file	(	snd_tplg_t *	tplg,
		const char *	infile,
		const char *	outfile )

Parse and build topology text file into binary file.

Parameters

tplg	Topology instance.
infile	Topology text input file to be parsed
outfile	Binary topology output file.

Returns: Zero on success, otherwise a negative error code

◆ snd_tplg_create()

snd_tplg_t * snd_tplg_create ( int flags )

Create a new topology parser instance.

Returns: New topology parser instance

◆ snd_tplg_decode()

int snd_tplg_decode	(	snd_tplg_t *	tplg,
		void *	bin,
		size_t	size,
		int	dflags )

Decode the binary topology contents.

Parameters

tplg	Topology instance.
bin	Binary topology input buffer.
size	Binary topology input buffer size.
dflags	- not used, must be set to 0.

Returns: Zero on success, otherwise a negative error code

◆ snd_tplg_free()

void snd_tplg_free ( snd_tplg_t * tplg )

Free a topology parser instance.

Parameters

tplg	Topology parser instance

◆ snd_tplg_load()

int snd_tplg_load	(	snd_tplg_t *	tplg,
		const char *	buf,
		size_t	size )

Load topology from the text buffer.

Parameters

tplg	Topology instance.
buf	Text buffer.
size	Text buffer size in bytes.

Returns: Zero on success, otherwise a negative error code

◆ snd_tplg_new()

snd_tplg_t * snd_tplg_new ( void )

Create a new topology parser instance.

Returns: New topology parser instance

◆ snd_tplg_save()

int snd_tplg_save	(	snd_tplg_t *	tplg,
		char **	dst,
		int	flags )

Save the topology to the text configuration string.

Parameters

tplg	Topology instance.
dst	A pointer to string with result (malloc).
flags	save mode

Returns: Zero on success, otherwise a negative error code

Valid flags are

SND_TPLG_SAVE_SORT
SND_TPLG_SAVE_GROUPS
SND_TPLG_SAVE_NOCHECK

◆ snd_tplg_set_manifest_data()

int snd_tplg_set_manifest_data	(	snd_tplg_t *	tplg,
		const void *	data,
		int	len )

Attach private data to topology manifest.

Parameters

tplg	Topology instance.
data	Private data.
len	Length of data in bytes.

Returns: Zero on success, otherwise a negative error code

◆ snd_tplg_set_version()

int snd_tplg_set_version	(	snd_tplg_t *	tplg,
		unsigned int	version )

Set an optional vendor specific version number.

Parameters

tplg	Topology instance.
version	Vendor specific version number.

Returns: Zero on success, otherwise a negative error code

◆ snd_tplg_verbose()

void snd_tplg_verbose	(	snd_tplg_t *	tplg,
		int	verbose )

Enable verbose reporting of binary file output.

Parameters

tplg	Topology Instance
verbose	Enable verbose output level if non zero

◆ snd_tplg_version()

const char * snd_tplg_version ( void )

Return the version of the topology library.

Returns: A static string with the version number.

Data Structures

Macros

Typedefs

Enumerations

Functions

Detailed Description

ALSA Topology Interface

Topology File Format

Controls

Control Operations

Control Access

Control TLV Data

Control Channel Mapping

Control Private Data

How to define an element with private data

To refer to a single data section:

To refer to multiple data sections:

Vendor Tokens

Vendor Tuples

Mixer Controls

Byte Controls

Enumerated Controls

DAPM Graph

DAPM Widgets

Widget Private Data

PCM Capabilities

PCM Configurations

PCM (Front-end DAI & DAI link)

Physical DAI Link Configurations

Physical DAI

Manifest Private Data

Include other files

Macro Definition Documentation

◆ SND_TPLG_CREATE_DAPM_NOSORT

◆ SND_TPLG_CREATE_VERBOSE

◆ SND_TPLG_INDEX_ALL

◆ SND_TPLG_MAX_CHAN

◆ SND_TPLG_SAVE_GROUPS

◆ SND_TPLG_SAVE_NOCHECK

◆ SND_TPLG_SAVE_SORT

Typedef Documentation

◆ snd_tplg_t

Enumeration Type Documentation

◆ snd_tplg_type

Function Documentation

◆ snd_tplg_add_object()

◆ snd_tplg_build()

◆ snd_tplg_build_bin()

◆ snd_tplg_build_file()

◆ snd_tplg_create()

◆ snd_tplg_decode()

◆ snd_tplg_free()

◆ snd_tplg_load()

◆ snd_tplg_new()

◆ snd_tplg_save()

◆ snd_tplg_set_manifest_data()

◆ snd_tplg_set_version()

◆ snd_tplg_verbose()

◆ snd_tplg_version()