https://www.alsa-project.org/main/api.php?action=feedcontributions&feedformat=atom&user=Mengdonglin 2026-04-18T07:11:35Z User contributions MediaWiki 1.39.0 https://www.alsa-project.org/main/index.php?title=ALSA_topology&diff=7191 2016-11-27T16:46:45Z

<p>Mengdonglin: /* Kernel */</p> <hr /> <div>ALSA Topology provides a method for audio drivers to load their mixers, routing, PCMs and capabilities from user space at runtime without changing any driver source code. The intention is to write the driver once and do the differentiation in topology.<br /> <br /> == '''Why we need topology?''' ==<br /> <br /> Current audio drivers typically hard code topology information in the driver sources:<br /> This tightly couples the audio driver to the development board making it time consuming to modify a driver to work on a different devices. <br /> The driver is also tightly coupled to the DSP firmware version meaning extra care is needed to keep the driver and firmware version in sync. New firmware features also mean driver updates.<br /> <br /> The ALSA topology project removes the need for re-writing or porting audio drivers to different devices or different firmwares:<br /> Drivers have no hard coded topology data meaning a single driver can be used on different devices by updating the topology data from the file system. <br /> Firmware updates can be pushed without having to update the drivers. The new firmware just needs to include an updated topology file describing the update.<br /> <br /> === Topology Objects ===<br /> <br /> The topology objects that can be configured by user space include: controls, widgets, routes, PCMs and configurations for physical DAI &amp; DAI links.<br /> <br /> Here is an example.<br /> <br /> [[File:Topology-objects.png]]<br /> <br /> == '''Topology Architecture''' ==<br /> <br /> [[File:Topology.png]]<br /> <br /> === User space ===<br /> The topology library is part of alsa-lib. Users can define topology objects that describe the topology of a customer firmware, e.g. for an ADSP embedded in SOC or an off-SOC codec. These topology objects can be defined either in a text configuration file or added via C API. And the topology library will parse them and generate a binary file for kernel. Please see the source code in directory src/topology of alsa-lib.<br /> <br /> The generated topology binary file consists of a manifest and a list of blocks. The manifest data provides overall info of the topology object types in the file, i.e. number of controls, widgets, routes, PCMs, physical DAI and physical DAI links. Each block consists of a blocker header and a specific type of topology objects. For the layout of file and topology object, please see the ABI file in alsa-lib include/sound/asoc.h and tlv.h<br /> <br /> ==== ''How to generate the topology binary file ====<br /> Users can define topology objects in a text configuration file. The syntax is based on alsaconf syntax, please see alsa-lib/include/alsa/topology.h<br /> Then users can use alsatplg, the topology tool in alsa-utils, to covert the topology text configuration file to the binary, via command &quot;alsatplg -c &lt;path-of-input-text-configuration-file&gt; -o &lt;path-of-output-binary-file&gt;&quot;. Please see the alsatplg code in directory topology of alsa-utils, and Intel Broadwell and Skylake configurations in alsa-lib/src/conf/topology as examples of the text configuration file.<br /> <br /> Users can also write their own application and call topology library API to add objects and generate the binary file. Please see alsa-lib/include/alsa/topology.h for the API definition.<br /> <br /> === Kernel === <br /> The topology kernel driver provides API for device drivers to load the topology binary file from the user space, then it will parse the ABI objects in the file, create controls, widgets, routes, front end DAI and DAI links (PCMs) and configure existing physical DAI and DAI links. It will also let the device driver do platform specific initialization on these objects via topology ops registered by the device driver. Please see code of sound/soc/soc-topology.c in kernel.<br /> <br /> ==== ''How device drivers use topology'' ====<br /> Intel Skylake platform driver is an example how device drivers use topology, please see code of sound/soc/intel/skylake/skl-topology.c in kernel.</div>

Mengdonglin https://www.alsa-project.org/main/index.php?title=ALSA_topology&diff=7190 2016-11-27T16:45:42Z

<p>Mengdonglin: /* How to generate the topology binary file */</p> <hr /> <div>ALSA Topology provides a method for audio drivers to load their mixers, routing, PCMs and capabilities from user space at runtime without changing any driver source code. The intention is to write the driver once and do the differentiation in topology.<br /> <br /> == '''Why we need topology?''' ==<br /> <br /> Current audio drivers typically hard code topology information in the driver sources:<br /> This tightly couples the audio driver to the development board making it time consuming to modify a driver to work on a different devices. <br /> The driver is also tightly coupled to the DSP firmware version meaning extra care is needed to keep the driver and firmware version in sync. New firmware features also mean driver updates.<br /> <br /> The ALSA topology project removes the need for re-writing or porting audio drivers to different devices or different firmwares:<br /> Drivers have no hard coded topology data meaning a single driver can be used on different devices by updating the topology data from the file system. <br /> Firmware updates can be pushed without having to update the drivers. The new firmware just needs to include an updated topology file describing the update.<br /> <br /> === Topology Objects ===<br /> <br /> The topology objects that can be configured by user space include: controls, widgets, routes, PCMs and configurations for physical DAI &amp; DAI links.<br /> <br /> Here is an example.<br /> <br /> [[File:Topology-objects.png]]<br /> <br /> == '''Topology Architecture''' ==<br /> <br /> [[File:Topology.png]]<br /> <br /> === User space ===<br /> The topology library is part of alsa-lib. Users can define topology objects that describe the topology of a customer firmware, e.g. for an ADSP embedded in SOC or an off-SOC codec. These topology objects can be defined either in a text configuration file or added via C API. And the topology library will parse them and generate a binary file for kernel. Please see the source code in directory src/topology of alsa-lib.<br /> <br /> The generated topology binary file consists of a manifest and a list of blocks. The manifest data provides overall info of the topology object types in the file, i.e. number of controls, widgets, routes, PCMs, physical DAI and physical DAI links. Each block consists of a blocker header and a specific type of topology objects. For the layout of file and topology object, please see the ABI file in alsa-lib include/sound/asoc.h and tlv.h<br /> <br /> ==== ''How to generate the topology binary file ====<br /> Users can define topology objects in a text configuration file. The syntax is based on alsaconf syntax, please see alsa-lib/include/alsa/topology.h<br /> Then users can use alsatplg, the topology tool in alsa-utils, to covert the topology text configuration file to the binary, via command &quot;alsatplg -c &lt;path-of-input-text-configuration-file&gt; -o &lt;path-of-output-binary-file&gt;&quot;. Please see the alsatplg code in directory topology of alsa-utils, and Intel Broadwell and Skylake configurations in alsa-lib/src/conf/topology as examples of the text configuration file.<br /> <br /> Users can also write their own application and call topology library API to add objects and generate the binary file. Please see alsa-lib/include/alsa/topology.h for the API definition.<br /> <br /> === Kernel === <br /> The topology kernel driver provides API for device drivers to load the topology binary file from the user space, then it will parse the ABI objects in the file, create controls, widgets, routes, front end DAI and DAI links (PCMs) and configure existing physical DAI and DAI links. It will also let the device driver do platform specific initialization on these objects via topology ops registered by the device driver. Please see code of sound/soc/soc-topology.c in kernel.<br /> And Skylake platform driver is an example how device drivers use topology, please see code of sound/soc/intel/skylake/skl-topology.c in kernel.</div>

Mengdonglin https://www.alsa-project.org/main/index.php?title=ALSA_topology&diff=7189 2016-11-27T16:41:48Z

<p>Mengdonglin: /* User space */</p> <hr /> <div>ALSA Topology provides a method for audio drivers to load their mixers, routing, PCMs and capabilities from user space at runtime without changing any driver source code. The intention is to write the driver once and do the differentiation in topology.<br /> <br /> == '''Why we need topology?''' ==<br /> <br /> Current audio drivers typically hard code topology information in the driver sources:<br /> This tightly couples the audio driver to the development board making it time consuming to modify a driver to work on a different devices. <br /> The driver is also tightly coupled to the DSP firmware version meaning extra care is needed to keep the driver and firmware version in sync. New firmware features also mean driver updates.<br /> <br /> The ALSA topology project removes the need for re-writing or porting audio drivers to different devices or different firmwares:<br /> Drivers have no hard coded topology data meaning a single driver can be used on different devices by updating the topology data from the file system. <br /> Firmware updates can be pushed without having to update the drivers. The new firmware just needs to include an updated topology file describing the update.<br /> <br /> === Topology Objects ===<br /> <br /> The topology objects that can be configured by user space include: controls, widgets, routes, PCMs and configurations for physical DAI &amp; DAI links.<br /> <br /> Here is an example.<br /> <br /> [[File:Topology-objects.png]]<br /> <br /> == '''Topology Architecture''' ==<br /> <br /> [[File:Topology.png]]<br /> <br /> === User space ===<br /> The topology library is part of alsa-lib. Users can define topology objects that describe the topology of a customer firmware, e.g. for an ADSP embedded in SOC or an off-SOC codec. These topology objects can be defined either in a text configuration file or added via C API. And the topology library will parse them and generate a binary file for kernel. Please see the source code in directory src/topology of alsa-lib.<br /> <br /> The generated topology binary file consists of a manifest and a list of blocks. The manifest data provides overall info of the topology object types in the file, i.e. number of controls, widgets, routes, PCMs, physical DAI and physical DAI links. Each block consists of a blocker header and a specific type of topology objects. For the layout of file and topology object, please see the ABI file in alsa-lib include/sound/asoc.h and tlv.h<br /> <br /> ==== ''How to generate the topology binary file ====<br /> Users can define topology objects in a text configuration file. The syntax is based on alsaconf syntax, please see alsa-lib/include/alsa/topology.h<br /> Then users can use alsatplg, the topology tool in alsa-utils, to covert the topology text configuration file to the binary, via command &quot;alsatplg -c &lt;path-of-input-text-configuration-file&gt; -o &lt;path-of-output-binary-file&gt;&quot;. Please see the alsatplg code in directory topology of alsa-utils.<br /> <br /> === Kernel === <br /> The topology kernel driver provides API for device drivers to load the topology binary file from the user space, then it will parse the ABI objects in the file, create controls, widgets, routes, front end DAI and DAI links (PCMs) and configure existing physical DAI and DAI links. It will also let the device driver do platform specific initialization on these objects via topology ops registered by the device driver. Please see code of sound/soc/soc-topology.c in kernel.<br /> And Skylake platform driver is an example how device drivers use topology, please see code of sound/soc/intel/skylake/skl-topology.c in kernel.</div>

Mengdonglin https://www.alsa-project.org/main/index.php?title=ALSA_topology&diff=7188 2016-11-27T16:12:51Z

<p>Mengdonglin: /* User space */</p> <hr /> <div>ALSA Topology provides a method for audio drivers to load their mixers, routing, PCMs and capabilities from user space at runtime without changing any driver source code. The intention is to write the driver once and do the differentiation in topology.<br /> <br /> == '''Why we need topology?''' ==<br /> <br /> Current audio drivers typically hard code topology information in the driver sources:<br /> This tightly couples the audio driver to the development board making it time consuming to modify a driver to work on a different devices. <br /> The driver is also tightly coupled to the DSP firmware version meaning extra care is needed to keep the driver and firmware version in sync. New firmware features also mean driver updates.<br /> <br /> The ALSA topology project removes the need for re-writing or porting audio drivers to different devices or different firmwares:<br /> Drivers have no hard coded topology data meaning a single driver can be used on different devices by updating the topology data from the file system. <br /> Firmware updates can be pushed without having to update the drivers. The new firmware just needs to include an updated topology file describing the update.<br /> <br /> === Topology Objects ===<br /> <br /> The topology objects that can be configured by user space include: controls, widgets, routes, PCMs and configurations for physical DAI &amp; DAI links.<br /> <br /> Here is an example.<br /> <br /> [[File:Topology-objects.png]]<br /> <br /> == '''Topology Architecture''' ==<br /> <br /> [[File:Topology.png]]<br /> <br /> === User space ===<br /> The topology library is part of alsa-lib. It can generate a binary file that describes the internal topology of a customer firmware, e.g. for an ADSP embedded in SOC or an off-SOC codec. Please see the source code in directory src/topology of alsa-lib.<br /> <br /> ==== ''How to generate topology info in user space'' ====<br /> TBD<br /> The topology tool in alsa-utils, alsatplg, can covert a topology text configuration file to the binary. Please see the source code in directory topology of alsa-utils.<br /> <br /> The generated topology binary file consists of a manifest and a list of blocks. The manifest data provides overall info of the topology object types in the file, i.e. number of controls, widgets, routes, PCMs, physical DAI and physical DAI links. Each block consists of a blocker header and a specific type of topology objects. For the layout of file and topology object, please see the ABI file in alsa-lib include/sound/asoc.h and tlv.h<br /> <br /> === Kernel === <br /> The topology kernel driver provides API for device drivers to load the topology binary file from the user space, then it will parse the ABI objects in the file, create controls, widgets, routes, front end DAI and DAI links (PCMs) and configure existing physical DAI and DAI links. It will also let the device driver do platform specific initialization on these objects via topology ops registered by the device driver. Please see code of sound/soc/soc-topology.c in kernel.<br /> And Skylake platform driver is an example how device drivers use topology, please see code of sound/soc/intel/skylake/skl-topology.c in kernel.</div>

Mengdonglin https://www.alsa-project.org/main/index.php?title=ALSA_topology&diff=7187 2016-11-27T16:11:55Z

<p>Mengdonglin: /* User space */</p> <hr /> <div>ALSA Topology provides a method for audio drivers to load their mixers, routing, PCMs and capabilities from user space at runtime without changing any driver source code. The intention is to write the driver once and do the differentiation in topology.<br /> <br /> == '''Why we need topology?''' ==<br /> <br /> Current audio drivers typically hard code topology information in the driver sources:<br /> This tightly couples the audio driver to the development board making it time consuming to modify a driver to work on a different devices. <br /> The driver is also tightly coupled to the DSP firmware version meaning extra care is needed to keep the driver and firmware version in sync. New firmware features also mean driver updates.<br /> <br /> The ALSA topology project removes the need for re-writing or porting audio drivers to different devices or different firmwares:<br /> Drivers have no hard coded topology data meaning a single driver can be used on different devices by updating the topology data from the file system. <br /> Firmware updates can be pushed without having to update the drivers. The new firmware just needs to include an updated topology file describing the update.<br /> <br /> === Topology Objects ===<br /> <br /> The topology objects that can be configured by user space include: controls, widgets, routes, PCMs and configurations for physical DAI &amp; DAI links.<br /> <br /> Here is an example.<br /> <br /> [[File:Topology-objects.png]]<br /> <br /> == '''Topology Architecture''' ==<br /> <br /> [[File:Topology.png]]<br /> <br /> === ''User space'' ===<br /> The topology library is part of alsa-lib. It can generate a binary file that describes the internal topology of a customer firmware, e.g. for an ADSP embedded in SOC or an off-SOC codec. Please see the source code in directory src/topology of alsa-lib.<br /> <br /> ==== How to generate topology info in user space ====<br /> TBD<br /> The topology tool in alsa-utils, alsatplg, can covert a topology text configuration file to the binary. Please see the source code in directory topology of alsa-utils.<br /> <br /> The generated topology binary file consists of a manifest and a list of blocks. The manifest data provides overall info of the topology object types in the file, i.e. number of controls, widgets, routes, PCMs, physical DAI and physical DAI links. Each block consists of a blocker header and a specific type of topology objects. For the layout of file and topology object, please see the ABI file in alsa-lib include/sound/asoc.h and tlv.h<br /> <br /> === Kernel === <br /> The topology kernel driver provides API for device drivers to load the topology binary file from the user space, then it will parse the ABI objects in the file, create controls, widgets, routes, front end DAI and DAI links (PCMs) and configure existing physical DAI and DAI links. It will also let the device driver do platform specific initialization on these objects via topology ops registered by the device driver. Please see code of sound/soc/soc-topology.c in kernel.<br /> And Skylake platform driver is an example how device drivers use topology, please see code of sound/soc/intel/skylake/skl-topology.c in kernel.</div>

Mengdonglin https://www.alsa-project.org/main/index.php?title=ALSA_topology&diff=7186 2016-11-27T16:11:34Z

<p>Mengdonglin: /* How device drivers use topology */</p> <hr /> <div>ALSA Topology provides a method for audio drivers to load their mixers, routing, PCMs and capabilities from user space at runtime without changing any driver source code. The intention is to write the driver once and do the differentiation in topology.<br /> <br /> == '''Why we need topology?''' ==<br /> <br /> Current audio drivers typically hard code topology information in the driver sources:<br /> This tightly couples the audio driver to the development board making it time consuming to modify a driver to work on a different devices. <br /> The driver is also tightly coupled to the DSP firmware version meaning extra care is needed to keep the driver and firmware version in sync. New firmware features also mean driver updates.<br /> <br /> The ALSA topology project removes the need for re-writing or porting audio drivers to different devices or different firmwares:<br /> Drivers have no hard coded topology data meaning a single driver can be used on different devices by updating the topology data from the file system. <br /> Firmware updates can be pushed without having to update the drivers. The new firmware just needs to include an updated topology file describing the update.<br /> <br /> === Topology Objects ===<br /> <br /> The topology objects that can be configured by user space include: controls, widgets, routes, PCMs and configurations for physical DAI &amp; DAI links.<br /> <br /> Here is an example.<br /> <br /> [[File:Topology-objects.png]]<br /> <br /> == '''Topology Architecture''' ==<br /> <br /> [[File:Topology.png]]<br /> <br /> === '''User space''' ===<br /> The topology library is part of alsa-lib. It can generate a binary file that describes the internal topology of a customer firmware, e.g. for an ADSP embedded in SOC or an off-SOC codec. Please see the source code in directory src/topology of alsa-lib.<br /> <br /> ==== How to generate topology info in user space ====<br /> TBD<br /> The topology tool in alsa-utils, alsatplg, can covert a topology text configuration file to the binary. Please see the source code in directory topology of alsa-utils.<br /> <br /> The generated topology binary file consists of a manifest and a list of blocks. The manifest data provides overall info of the topology object types in the file, i.e. number of controls, widgets, routes, PCMs, physical DAI and physical DAI links. Each block consists of a blocker header and a specific type of topology objects. For the layout of file and topology object, please see the ABI file in alsa-lib include/sound/asoc.h and tlv.h<br /> <br /> === Kernel === <br /> The topology kernel driver provides API for device drivers to load the topology binary file from the user space, then it will parse the ABI objects in the file, create controls, widgets, routes, front end DAI and DAI links (PCMs) and configure existing physical DAI and DAI links. It will also let the device driver do platform specific initialization on these objects via topology ops registered by the device driver. Please see code of sound/soc/soc-topology.c in kernel.<br /> And Skylake platform driver is an example how device drivers use topology, please see code of sound/soc/intel/skylake/skl-topology.c in kernel.</div>

Mengdonglin https://www.alsa-project.org/main/index.php?title=ALSA_topology&diff=7185 2016-11-27T16:11:14Z

<p>Mengdonglin: /* User space */</p> <hr /> <div>ALSA Topology provides a method for audio drivers to load their mixers, routing, PCMs and capabilities from user space at runtime without changing any driver source code. The intention is to write the driver once and do the differentiation in topology.<br /> <br /> == '''Why we need topology?''' ==<br /> <br /> Current audio drivers typically hard code topology information in the driver sources:<br /> This tightly couples the audio driver to the development board making it time consuming to modify a driver to work on a different devices. <br /> The driver is also tightly coupled to the DSP firmware version meaning extra care is needed to keep the driver and firmware version in sync. New firmware features also mean driver updates.<br /> <br /> The ALSA topology project removes the need for re-writing or porting audio drivers to different devices or different firmwares:<br /> Drivers have no hard coded topology data meaning a single driver can be used on different devices by updating the topology data from the file system. <br /> Firmware updates can be pushed without having to update the drivers. The new firmware just needs to include an updated topology file describing the update.<br /> <br /> === Topology Objects ===<br /> <br /> The topology objects that can be configured by user space include: controls, widgets, routes, PCMs and configurations for physical DAI &amp; DAI links.<br /> <br /> Here is an example.<br /> <br /> [[File:Topology-objects.png]]<br /> <br /> == '''Topology Architecture''' ==<br /> <br /> [[File:Topology.png]]<br /> <br /> === '''User space''' ===<br /> The topology library is part of alsa-lib. It can generate a binary file that describes the internal topology of a customer firmware, e.g. for an ADSP embedded in SOC or an off-SOC codec. Please see the source code in directory src/topology of alsa-lib.<br /> <br /> ==== How to generate topology info in user space ====<br /> TBD<br /> The topology tool in alsa-utils, alsatplg, can covert a topology text configuration file to the binary. Please see the source code in directory topology of alsa-utils.<br /> <br /> The generated topology binary file consists of a manifest and a list of blocks. The manifest data provides overall info of the topology object types in the file, i.e. number of controls, widgets, routes, PCMs, physical DAI and physical DAI links. Each block consists of a blocker header and a specific type of topology objects. For the layout of file and topology object, please see the ABI file in alsa-lib include/sound/asoc.h and tlv.h<br /> <br /> === Kernel === <br /> The topology kernel driver provides API for device drivers to load the topology binary file from the user space, then it will parse the ABI objects in the file, create controls, widgets, routes, front end DAI and DAI links (PCMs) and configure existing physical DAI and DAI links. It will also let the device driver do platform specific initialization on these objects via topology ops registered by the device driver. Please see code of sound/soc/soc-topology.c in kernel.<br /> And Skylake platform driver is an example how device drivers use topology, please see code of sound/soc/intel/skylake/skl-topology.c in kernel.<br /> <br /> == '''How device drivers use topology ''' ==<br /> TBD</div>

Mengdonglin https://www.alsa-project.org/main/index.php?title=ALSA_topology&diff=7184 2016-11-27T16:10:54Z

<p>Mengdonglin: /* 'How to generate topology info in user space' */</p> <hr /> <div>ALSA Topology provides a method for audio drivers to load their mixers, routing, PCMs and capabilities from user space at runtime without changing any driver source code. The intention is to write the driver once and do the differentiation in topology.<br /> <br /> == '''Why we need topology?''' ==<br /> <br /> Current audio drivers typically hard code topology information in the driver sources:<br /> This tightly couples the audio driver to the development board making it time consuming to modify a driver to work on a different devices. <br /> The driver is also tightly coupled to the DSP firmware version meaning extra care is needed to keep the driver and firmware version in sync. New firmware features also mean driver updates.<br /> <br /> The ALSA topology project removes the need for re-writing or porting audio drivers to different devices or different firmwares:<br /> Drivers have no hard coded topology data meaning a single driver can be used on different devices by updating the topology data from the file system. <br /> Firmware updates can be pushed without having to update the drivers. The new firmware just needs to include an updated topology file describing the update.<br /> <br /> === Topology Objects ===<br /> <br /> The topology objects that can be configured by user space include: controls, widgets, routes, PCMs and configurations for physical DAI &amp; DAI links.<br /> <br /> Here is an example.<br /> <br /> [[File:Topology-objects.png]]<br /> <br /> == '''Topology Architecture''' ==<br /> <br /> [[File:Topology.png]]<br /> <br /> === User space ===<br /> The topology library is part of alsa-lib. It can generate a binary file that describes the internal topology of a customer firmware, e.g. for an ADSP embedded in SOC or an off-SOC codec. Please see the source code in directory src/topology of alsa-lib.<br /> <br /> ==== How to generate topology info in user space ====<br /> TBD<br /> The topology tool in alsa-utils, alsatplg, can covert a topology text configuration file to the binary. Please see the source code in directory topology of alsa-utils.<br /> <br /> The generated topology binary file consists of a manifest and a list of blocks. The manifest data provides overall info of the topology object types in the file, i.e. number of controls, widgets, routes, PCMs, physical DAI and physical DAI links. Each block consists of a blocker header and a specific type of topology objects. For the layout of file and topology object, please see the ABI file in alsa-lib include/sound/asoc.h and tlv.h<br /> <br /> === Kernel === <br /> The topology kernel driver provides API for device drivers to load the topology binary file from the user space, then it will parse the ABI objects in the file, create controls, widgets, routes, front end DAI and DAI links (PCMs) and configure existing physical DAI and DAI links. It will also let the device driver do platform specific initialization on these objects via topology ops registered by the device driver. Please see code of sound/soc/soc-topology.c in kernel.<br /> And Skylake platform driver is an example how device drivers use topology, please see code of sound/soc/intel/skylake/skl-topology.c in kernel.<br /> <br /> == '''How device drivers use topology ''' ==<br /> TBD</div>

Mengdonglin https://www.alsa-project.org/main/index.php?title=ALSA_topology&diff=7183 2016-11-27T16:10:29Z

<p>Mengdonglin: /* User space */</p> <hr /> <div>ALSA Topology provides a method for audio drivers to load their mixers, routing, PCMs and capabilities from user space at runtime without changing any driver source code. The intention is to write the driver once and do the differentiation in topology.<br /> <br /> == '''Why we need topology?''' ==<br /> <br /> Current audio drivers typically hard code topology information in the driver sources:<br /> This tightly couples the audio driver to the development board making it time consuming to modify a driver to work on a different devices. <br /> The driver is also tightly coupled to the DSP firmware version meaning extra care is needed to keep the driver and firmware version in sync. New firmware features also mean driver updates.<br /> <br /> The ALSA topology project removes the need for re-writing or porting audio drivers to different devices or different firmwares:<br /> Drivers have no hard coded topology data meaning a single driver can be used on different devices by updating the topology data from the file system. <br /> Firmware updates can be pushed without having to update the drivers. The new firmware just needs to include an updated topology file describing the update.<br /> <br /> === Topology Objects ===<br /> <br /> The topology objects that can be configured by user space include: controls, widgets, routes, PCMs and configurations for physical DAI &amp; DAI links.<br /> <br /> Here is an example.<br /> <br /> [[File:Topology-objects.png]]<br /> <br /> == '''Topology Architecture''' ==<br /> <br /> [[File:Topology.png]]<br /> <br /> === User space ===<br /> The topology library is part of alsa-lib. It can generate a binary file that describes the internal topology of a customer firmware, e.g. for an ADSP embedded in SOC or an off-SOC codec. Please see the source code in directory src/topology of alsa-lib.<br /> <br /> ==== 'How to generate topology info in user space' ====<br /> TBD<br /> The topology tool in alsa-utils, alsatplg, can covert a topology text configuration file to the binary. Please see the source code in directory topology of alsa-utils.<br /> <br /> The generated topology binary file consists of a manifest and a list of blocks. The manifest data provides overall info of the topology object types in the file, i.e. number of controls, widgets, routes, PCMs, physical DAI and physical DAI links. Each block consists of a blocker header and a specific type of topology objects. For the layout of file and topology object, please see the ABI file in alsa-lib include/sound/asoc.h and tlv.h<br /> <br /> === Kernel === <br /> The topology kernel driver provides API for device drivers to load the topology binary file from the user space, then it will parse the ABI objects in the file, create controls, widgets, routes, front end DAI and DAI links (PCMs) and configure existing physical DAI and DAI links. It will also let the device driver do platform specific initialization on these objects via topology ops registered by the device driver. Please see code of sound/soc/soc-topology.c in kernel.<br /> And Skylake platform driver is an example how device drivers use topology, please see code of sound/soc/intel/skylake/skl-topology.c in kernel.<br /> <br /> == '''How device drivers use topology ''' ==<br /> TBD</div>

Mengdonglin https://www.alsa-project.org/main/index.php?title=ALSA_topology&diff=7182 2016-11-27T16:10:05Z

<p>Mengdonglin: /* User space */</p> <hr /> <div>ALSA Topology provides a method for audio drivers to load their mixers, routing, PCMs and capabilities from user space at runtime without changing any driver source code. The intention is to write the driver once and do the differentiation in topology.<br /> <br /> == '''Why we need topology?''' ==<br /> <br /> Current audio drivers typically hard code topology information in the driver sources:<br /> This tightly couples the audio driver to the development board making it time consuming to modify a driver to work on a different devices. <br /> The driver is also tightly coupled to the DSP firmware version meaning extra care is needed to keep the driver and firmware version in sync. New firmware features also mean driver updates.<br /> <br /> The ALSA topology project removes the need for re-writing or porting audio drivers to different devices or different firmwares:<br /> Drivers have no hard coded topology data meaning a single driver can be used on different devices by updating the topology data from the file system. <br /> Firmware updates can be pushed without having to update the drivers. The new firmware just needs to include an updated topology file describing the update.<br /> <br /> === Topology Objects ===<br /> <br /> The topology objects that can be configured by user space include: controls, widgets, routes, PCMs and configurations for physical DAI &amp; DAI links.<br /> <br /> Here is an example.<br /> <br /> [[File:Topology-objects.png]]<br /> <br /> == '''Topology Architecture''' ==<br /> <br /> [[File:Topology.png]]<br /> <br /> === User space ===<br /> The topology library is part of alsa-lib. It can generate a binary file that describes the internal topology of a customer firmware, e.g. for an ADSP embedded in SOC or an off-SOC codec. Please see the source code in directory src/topology of alsa-lib.<br /> <br /> ==== '''How to generate topology info in user space''' ====<br /> TBD<br /> The topology tool in alsa-utils, alsatplg, can covert a topology text configuration file to the binary. Please see the source code in directory topology of alsa-utils.<br /> <br /> The generated topology binary file consists of a manifest and a list of blocks. The manifest data provides overall info of the topology object types in the file, i.e. number of controls, widgets, routes, PCMs, physical DAI and physical DAI links. Each block consists of a blocker header and a specific type of topology objects. For the layout of file and topology object, please see the ABI file in alsa-lib include/sound/asoc.h and tlv.h<br /> <br /> === Kernel === <br /> The topology kernel driver provides API for device drivers to load the topology binary file from the user space, then it will parse the ABI objects in the file, create controls, widgets, routes, front end DAI and DAI links (PCMs) and configure existing physical DAI and DAI links. It will also let the device driver do platform specific initialization on these objects via topology ops registered by the device driver. Please see code of sound/soc/soc-topology.c in kernel.<br /> And Skylake platform driver is an example how device drivers use topology, please see code of sound/soc/intel/skylake/skl-topology.c in kernel.<br /> <br /> == '''How device drivers use topology ''' ==<br /> TBD</div>

Mengdonglin https://www.alsa-project.org/main/index.php?title=ALSA_topology&diff=7181 2016-11-27T16:09:19Z

<p>Mengdonglin: /* Topology Objects */</p> <hr /> <div>ALSA Topology provides a method for audio drivers to load their mixers, routing, PCMs and capabilities from user space at runtime without changing any driver source code. The intention is to write the driver once and do the differentiation in topology.<br /> <br /> == '''Why we need topology?''' ==<br /> <br /> Current audio drivers typically hard code topology information in the driver sources:<br /> This tightly couples the audio driver to the development board making it time consuming to modify a driver to work on a different devices. <br /> The driver is also tightly coupled to the DSP firmware version meaning extra care is needed to keep the driver and firmware version in sync. New firmware features also mean driver updates.<br /> <br /> The ALSA topology project removes the need for re-writing or porting audio drivers to different devices or different firmwares:<br /> Drivers have no hard coded topology data meaning a single driver can be used on different devices by updating the topology data from the file system. <br /> Firmware updates can be pushed without having to update the drivers. The new firmware just needs to include an updated topology file describing the update.<br /> <br /> === Topology Objects ===<br /> <br /> The topology objects that can be configured by user space include: controls, widgets, routes, PCMs and configurations for physical DAI &amp; DAI links.<br /> <br /> Here is an example.<br /> <br /> [[File:Topology-objects.png]]<br /> <br /> == '''Topology Architecture''' ==<br /> <br /> [[File:Topology.png]]<br /> <br /> === User space ===<br /> The topology library is part of alsa-lib. It can generate a binary file that describes the internal topology of a customer firmware, e.g. for an ADSP embedded in SOC or an off-SOC codec. Please see the source code in directory src/topology of alsa-lib.<br /> <br /> The topology tool in alsa-utils, alsatplg, can covert a topology text configuration file to the binary. Please see the source code in directory topology of alsa-utils.<br /> <br /> The generated topology binary file consists of a manifest and a list of blocks. The manifest data provides overall info of the topology object types in the file, i.e. number of controls, widgets, routes, PCMs, physical DAI and physical DAI links. Each block consists of a blocker header and a specific type of topology objects. For the layout of file and topology object, please see the ABI file in alsa-lib include/sound/asoc.h and tlv.h<br /> <br /> === Kernel === <br /> The topology kernel driver provides API for device drivers to load the topology binary file from the user space, then it will parse the ABI objects in the file, create controls, widgets, routes, front end DAI and DAI links (PCMs) and configure existing physical DAI and DAI links. It will also let the device driver do platform specific initialization on these objects via topology ops registered by the device driver. Please see code of sound/soc/soc-topology.c in kernel.<br /> And Skylake platform driver is an example how device drivers use topology, please see code of sound/soc/intel/skylake/skl-topology.c in kernel.<br /> <br /> == '''How device drivers use topology ''' ==<br /> TBD</div>

Mengdonglin https://www.alsa-project.org/main/index.php?title=ALSA_topology&diff=7180 2016-11-27T16:08:54Z

<p>Mengdonglin: /* Topology Objects */</p> <hr /> <div>ALSA Topology provides a method for audio drivers to load their mixers, routing, PCMs and capabilities from user space at runtime without changing any driver source code. The intention is to write the driver once and do the differentiation in topology.<br /> <br /> == '''Why we need topology?''' ==<br /> <br /> Current audio drivers typically hard code topology information in the driver sources:<br /> This tightly couples the audio driver to the development board making it time consuming to modify a driver to work on a different devices. <br /> The driver is also tightly coupled to the DSP firmware version meaning extra care is needed to keep the driver and firmware version in sync. New firmware features also mean driver updates.<br /> <br /> The ALSA topology project removes the need for re-writing or porting audio drivers to different devices or different firmwares:<br /> Drivers have no hard coded topology data meaning a single driver can be used on different devices by updating the topology data from the file system. <br /> Firmware updates can be pushed without having to update the drivers. The new firmware just needs to include an updated topology file describing the update.<br /> <br /> === '''Topology Objects''' ===<br /> <br /> The topology objects that can be configured by user space include: controls, widgets, routes, PCMs and configurations for physical DAI &amp; DAI links.<br /> <br /> Here is an example.<br /> <br /> [[File:Topology-objects.png]]<br /> <br /> == '''Topology Architecture''' ==<br /> <br /> [[File:Topology.png]]<br /> <br /> === User space ===<br /> The topology library is part of alsa-lib. It can generate a binary file that describes the internal topology of a customer firmware, e.g. for an ADSP embedded in SOC or an off-SOC codec. Please see the source code in directory src/topology of alsa-lib.<br /> <br /> The topology tool in alsa-utils, alsatplg, can covert a topology text configuration file to the binary. Please see the source code in directory topology of alsa-utils.<br /> <br /> The generated topology binary file consists of a manifest and a list of blocks. The manifest data provides overall info of the topology object types in the file, i.e. number of controls, widgets, routes, PCMs, physical DAI and physical DAI links. Each block consists of a blocker header and a specific type of topology objects. For the layout of file and topology object, please see the ABI file in alsa-lib include/sound/asoc.h and tlv.h<br /> <br /> === Kernel === <br /> The topology kernel driver provides API for device drivers to load the topology binary file from the user space, then it will parse the ABI objects in the file, create controls, widgets, routes, front end DAI and DAI links (PCMs) and configure existing physical DAI and DAI links. It will also let the device driver do platform specific initialization on these objects via topology ops registered by the device driver. Please see code of sound/soc/soc-topology.c in kernel.<br /> And Skylake platform driver is an example how device drivers use topology, please see code of sound/soc/intel/skylake/skl-topology.c in kernel.<br /> <br /> == '''How device drivers use topology ''' ==<br /> TBD</div>

Mengdonglin https://www.alsa-project.org/main/index.php?title=ALSA_topology&diff=7179 2016-11-27T16:08:11Z

<p>Mengdonglin: /* Topology Objects */</p> <hr /> <div>ALSA Topology provides a method for audio drivers to load their mixers, routing, PCMs and capabilities from user space at runtime without changing any driver source code. The intention is to write the driver once and do the differentiation in topology.<br /> <br /> == '''Why we need topology?''' ==<br /> <br /> Current audio drivers typically hard code topology information in the driver sources:<br /> This tightly couples the audio driver to the development board making it time consuming to modify a driver to work on a different devices. <br /> The driver is also tightly coupled to the DSP firmware version meaning extra care is needed to keep the driver and firmware version in sync. New firmware features also mean driver updates.<br /> <br /> The ALSA topology project removes the need for re-writing or porting audio drivers to different devices or different firmwares:<br /> Drivers have no hard coded topology data meaning a single driver can be used on different devices by updating the topology data from the file system. <br /> Firmware updates can be pushed without having to update the drivers. The new firmware just needs to include an updated topology file describing the update.<br /> <br /> == '''Topology Objects''' ==<br /> <br /> The topology objects that can be configured by user space include: controls, widgets, routes, PCMs and configurations for physical DAI &amp; DAI links.<br /> <br /> Here is an example.<br /> <br /> [[File:Topology-objects.png]]<br /> <br /> == '''Topology Architecture''' ==<br /> <br /> [[File:Topology.png]]<br /> <br /> === User space ===<br /> The topology library is part of alsa-lib. It can generate a binary file that describes the internal topology of a customer firmware, e.g. for an ADSP embedded in SOC or an off-SOC codec. Please see the source code in directory src/topology of alsa-lib.<br /> <br /> The topology tool in alsa-utils, alsatplg, can covert a topology text configuration file to the binary. Please see the source code in directory topology of alsa-utils.<br /> <br /> The generated topology binary file consists of a manifest and a list of blocks. The manifest data provides overall info of the topology object types in the file, i.e. number of controls, widgets, routes, PCMs, physical DAI and physical DAI links. Each block consists of a blocker header and a specific type of topology objects. For the layout of file and topology object, please see the ABI file in alsa-lib include/sound/asoc.h and tlv.h<br /> <br /> === Kernel === <br /> The topology kernel driver provides API for device drivers to load the topology binary file from the user space, then it will parse the ABI objects in the file, create controls, widgets, routes, front end DAI and DAI links (PCMs) and configure existing physical DAI and DAI links. It will also let the device driver do platform specific initialization on these objects via topology ops registered by the device driver. Please see code of sound/soc/soc-topology.c in kernel.<br /> And Skylake platform driver is an example how device drivers use topology, please see code of sound/soc/intel/skylake/skl-topology.c in kernel.<br /> <br /> == '''How device drivers use topology ''' ==<br /> TBD</div>

Mengdonglin https://www.alsa-project.org/main/index.php?title=ALSA_topology&diff=7178 2016-11-27T16:07:52Z

<p>Mengdonglin: /* How to generate topology info in user space */</p> <hr /> <div>ALSA Topology provides a method for audio drivers to load their mixers, routing, PCMs and capabilities from user space at runtime without changing any driver source code. The intention is to write the driver once and do the differentiation in topology.<br /> <br /> == '''Why we need topology?''' ==<br /> <br /> Current audio drivers typically hard code topology information in the driver sources:<br /> This tightly couples the audio driver to the development board making it time consuming to modify a driver to work on a different devices. <br /> The driver is also tightly coupled to the DSP firmware version meaning extra care is needed to keep the driver and firmware version in sync. New firmware features also mean driver updates.<br /> <br /> The ALSA topology project removes the need for re-writing or porting audio drivers to different devices or different firmwares:<br /> Drivers have no hard coded topology data meaning a single driver can be used on different devices by updating the topology data from the file system. <br /> Firmware updates can be pushed without having to update the drivers. The new firmware just needs to include an updated topology file describing the update.<br /> <br /> == '''Topology Objects''' ==<br /> <br /> The topology objects that can be configured by user space include: controls, widgets, routes, PCMs and configurations for physical DAI &amp; DAI links.<br /> <br /> Here is an example.<br /> <br /> [[File:Topology-objects.png]]<br /> <br /> == '''Topology Architecture''' ==<br /> <br /> [[File:Topology.png]]<br /> <br /> === User space ===<br /> The topology library is part of alsa-lib. It can generate a binary file that describes the internal topology of a customer firmware, e.g. for an ADSP embedded in SOC or an off-SOC codec. Please see the source code in directory src/topology of alsa-lib.<br /> <br /> The topology tool in alsa-utils, alsatplg, can covert a topology text configuration file to the binary. Please see the source code in directory topology of alsa-utils.<br /> <br /> The generated topology binary file consists of a manifest and a list of blocks. The manifest data provides overall info of the topology object types in the file, i.e. number of controls, widgets, routes, PCMs, physical DAI and physical DAI links. Each block consists of a blocker header and a specific type of topology objects. For the layout of file and topology object, please see the ABI file in alsa-lib include/sound/asoc.h and tlv.h<br /> <br /> === Kernel === <br /> The topology kernel driver provides API for device drivers to load the topology binary file from the user space, then it will parse the ABI objects in the file, create controls, widgets, routes, front end DAI and DAI links (PCMs) and configure existing physical DAI and DAI links. It will also let the device driver do platform specific initialization on these objects via topology ops registered by the device driver. Please see code of sound/soc/soc-topology.c in kernel.<br /> And Skylake platform driver is an example how device drivers use topology, please see code of sound/soc/intel/skylake/skl-topology.c in kernel.<br /> <br /> == '''Topology Objects''' ==<br /> <br /> Topology objects can be loaded from the user space include controls, widgets, routes, PCMs and configurations for physical DAI &amp; DAI links.<br /> Please check alsa-lib include/topology.h, which include the syntax for all supported objects.<br /> <br /> Here is an example.<br /> <br /> [[File:Topology-objects.png]]<br /> <br /> == '''How device drivers use topology ''' ==<br /> TBD</div>

Mengdonglin https://www.alsa-project.org/main/index.php?title=ALSA_topology&diff=7177 2016-11-27T16:07:02Z

<p>Mengdonglin: /* Topology Architecture */</p> <hr /> <div>ALSA Topology provides a method for audio drivers to load their mixers, routing, PCMs and capabilities from user space at runtime without changing any driver source code. The intention is to write the driver once and do the differentiation in topology.<br /> <br /> == '''Why we need topology?''' ==<br /> <br /> Current audio drivers typically hard code topology information in the driver sources:<br /> This tightly couples the audio driver to the development board making it time consuming to modify a driver to work on a different devices. <br /> The driver is also tightly coupled to the DSP firmware version meaning extra care is needed to keep the driver and firmware version in sync. New firmware features also mean driver updates.<br /> <br /> The ALSA topology project removes the need for re-writing or porting audio drivers to different devices or different firmwares:<br /> Drivers have no hard coded topology data meaning a single driver can be used on different devices by updating the topology data from the file system. <br /> Firmware updates can be pushed without having to update the drivers. The new firmware just needs to include an updated topology file describing the update.<br /> <br /> == '''Topology Objects''' ==<br /> <br /> The topology objects that can be configured by user space include: controls, widgets, routes, PCMs and configurations for physical DAI &amp; DAI links.<br /> <br /> Here is an example.<br /> <br /> [[File:Topology-objects.png]]<br /> <br /> == '''Topology Architecture''' ==<br /> <br /> [[File:Topology.png]]<br /> <br /> === User space ===<br /> The topology library is part of alsa-lib. It can generate a binary file that describes the internal topology of a customer firmware, e.g. for an ADSP embedded in SOC or an off-SOC codec. Please see the source code in directory src/topology of alsa-lib.<br /> <br /> The topology tool in alsa-utils, alsatplg, can covert a topology text configuration file to the binary. Please see the source code in directory topology of alsa-utils.<br /> <br /> The generated topology binary file consists of a manifest and a list of blocks. The manifest data provides overall info of the topology object types in the file, i.e. number of controls, widgets, routes, PCMs, physical DAI and physical DAI links. Each block consists of a blocker header and a specific type of topology objects. For the layout of file and topology object, please see the ABI file in alsa-lib include/sound/asoc.h and tlv.h<br /> <br /> === Kernel === <br /> The topology kernel driver provides API for device drivers to load the topology binary file from the user space, then it will parse the ABI objects in the file, create controls, widgets, routes, front end DAI and DAI links (PCMs) and configure existing physical DAI and DAI links. It will also let the device driver do platform specific initialization on these objects via topology ops registered by the device driver. Please see code of sound/soc/soc-topology.c in kernel.<br /> And Skylake platform driver is an example how device drivers use topology, please see code of sound/soc/intel/skylake/skl-topology.c in kernel.<br /> <br /> == '''Topology Objects''' ==<br /> <br /> Topology objects can be loaded from the user space include controls, widgets, routes, PCMs and configurations for physical DAI &amp; DAI links.<br /> Please check alsa-lib include/topology.h, which include the syntax for all supported objects.<br /> <br /> Here is an example.<br /> <br /> [[File:Topology-objects.png]]<br /> <br /> == '''How to generate topology info in user space''' ==<br /> TBD<br /> <br /> == '''How device drivers use topology ''' ==<br /> TBD</div>

Mengdonglin https://www.alsa-project.org/main/index.php?title=ALSA_topology&diff=7176 2016-11-27T16:00:28Z

<p>Mengdonglin: /* Kernel */</p> <hr /> <div>ALSA Topology provides a method for audio drivers to load their mixers, routing, PCMs and capabilities from user space at runtime without changing any driver source code. The intention is to write the driver once and do the differentiation in topology.<br /> <br /> == '''Why we need topology?''' ==<br /> <br /> Current audio drivers typically hard code topology information in the driver sources:<br /> This tightly couples the audio driver to the development board making it time consuming to modify a driver to work on a different devices. <br /> The driver is also tightly coupled to the DSP firmware version meaning extra care is needed to keep the driver and firmware version in sync. New firmware features also mean driver updates.<br /> <br /> The ALSA topology project removes the need for re-writing or porting audio drivers to different devices or different firmwares:<br /> Drivers have no hard coded topology data meaning a single driver can be used on different devices by updating the topology data from the file system. <br /> Firmware updates can be pushed without having to update the drivers. The new firmware just needs to include an updated topology file describing the update.<br /> <br /> == '''Topology Architecture''' ==<br /> <br /> [[File:Topology.png]]<br /> <br /> === User space ===<br /> The topology library is part of alsa-lib. It can generate a binary file that describes the internal topology of a customer firmware, e.g. for an ADSP embedded in SOC or an off-SOC codec. Please see the source code in directory src/topology of alsa-lib.<br /> <br /> The topology tool in alsa-utils, alsatplg, can covert a topology text configuration file to the binary. Please see the source code in directory topology of alsa-utils.<br /> <br /> The generated topology binary file consists of a manifest and a list of blocks. The manifest data provides overall info of the topology object types in the file, i.e. number of controls, widgets, routes, PCMs, physical DAI and physical DAI links. Each block consists of a blocker header and a specific type of topology objects. For the layout of file and topology object, please see the ABI file in alsa-lib include/sound/asoc.h and tlv.h<br /> <br /> === Kernel === <br /> The topology kernel driver provides API for device drivers to load the topology binary file from the user space, then it will parse the ABI objects in the file, create controls, widgets, routes, front end DAI and DAI links (PCMs) and configure existing physical DAI and DAI links. It will also let the device driver do platform specific initialization on these objects via topology ops registered by the device driver. Please see code of sound/soc/soc-topology.c in kernel.<br /> And Skylake platform driver is an example how device drivers use topology, please see code of sound/soc/intel/skylake/skl-topology.c in kernel.<br /> <br /> == '''Topology Objects''' ==<br /> <br /> Topology objects can be loaded from the user space include controls, widgets, routes, PCMs and configurations for physical DAI &amp; DAI links.<br /> Please check alsa-lib include/topology.h, which include the syntax for all supported objects.<br /> <br /> Here is an example.<br /> <br /> [[File:Topology-objects.png]]<br /> <br /> == '''How to generate topology info in user space''' ==<br /> TBD<br /> <br /> == '''How device drivers use topology ''' ==<br /> TBD</div>

Mengdonglin https://www.alsa-project.org/main/index.php?title=ALSA_topology&diff=7175 2016-11-27T15:26:53Z

<p>Mengdonglin: /* User space */</p> <hr /> <div>ALSA Topology provides a method for audio drivers to load their mixers, routing, PCMs and capabilities from user space at runtime without changing any driver source code. The intention is to write the driver once and do the differentiation in topology.<br /> <br /> == '''Why we need topology?''' ==<br /> <br /> Current audio drivers typically hard code topology information in the driver sources:<br /> This tightly couples the audio driver to the development board making it time consuming to modify a driver to work on a different devices. <br /> The driver is also tightly coupled to the DSP firmware version meaning extra care is needed to keep the driver and firmware version in sync. New firmware features also mean driver updates.<br /> <br /> The ALSA topology project removes the need for re-writing or porting audio drivers to different devices or different firmwares:<br /> Drivers have no hard coded topology data meaning a single driver can be used on different devices by updating the topology data from the file system. <br /> Firmware updates can be pushed without having to update the drivers. The new firmware just needs to include an updated topology file describing the update.<br /> <br /> == '''Topology Architecture''' ==<br /> <br /> [[File:Topology.png]]<br /> <br /> === User space ===<br /> The topology library is part of alsa-lib. It can generate a binary file that describes the internal topology of a customer firmware, e.g. for an ADSP embedded in SOC or an off-SOC codec. Please see the source code in directory src/topology of alsa-lib.<br /> <br /> The topology tool in alsa-utils, alsatplg, can covert a topology text configuration file to the binary. Please see the source code in directory topology of alsa-utils.<br /> <br /> The generated topology binary file consists of a manifest and a list of blocks. The manifest data provides overall info of the topology object types in the file, i.e. number of controls, widgets, routes, PCMs, physical DAI and physical DAI links. Each block consists of a blocker header and a specific type of topology objects. For the layout of file and topology object, please see the ABI file in alsa-lib include/sound/asoc.h and tlv.h<br /> <br /> === Kernel === <br /> Provide generic support to import the topology info from user space to ASoC framework and generate different audio components for the sound card.<br /> <br /> == '''Topology Objects''' ==<br /> <br /> Topology objects can be loaded from the user space include controls, widgets, routes, PCMs and configurations for physical DAI &amp; DAI links.<br /> Please check alsa-lib include/topology.h, which include the syntax for all supported objects.<br /> <br /> Here is an example.<br /> <br /> [[File:Topology-objects.png]]<br /> <br /> == '''How to generate topology info in user space''' ==<br /> TBD<br /> <br /> == '''How device drivers use topology ''' ==<br /> TBD</div>

Mengdonglin https://www.alsa-project.org/main/index.php?title=ALSA_topology&diff=7174 2016-11-10T01:24:53Z

<p>Mengdonglin: </p> <hr /> <div>ALSA Topology provides a method for audio drivers to load their mixers, routing, PCMs and capabilities from user space at runtime without changing any driver source code. The intention is to write the driver once and do the differentiation in topology.<br /> <br /> == '''Why we need topology?''' ==<br /> <br /> Current audio drivers typically hard code topology information in the driver sources:<br /> This tightly couples the audio driver to the development board making it time consuming to modify a driver to work on a different devices. <br /> The driver is also tightly coupled to the DSP firmware version meaning extra care is needed to keep the driver and firmware version in sync. New firmware features also mean driver updates.<br /> <br /> The ALSA topology project removes the need for re-writing or porting audio drivers to different devices or different firmwares:<br /> Drivers have no hard coded topology data meaning a single driver can be used on different devices by updating the topology data from the file system. <br /> Firmware updates can be pushed without having to update the drivers. The new firmware just needs to include an updated topology file describing the update.<br /> <br /> == '''Topology Architecture''' ==<br /> <br /> [[File:Topology.png]]<br /> <br /> === User space ===<br /> Provide a tool &amp; library to generate a binary file that describes the internal topology of a customer firmware, e.g. for an ADSP in SOC or 3rd party codec. Please check source files of alsa-lib in directory src/topology.<br /> <br /> === Kernel === <br /> Provide generic support to import the topology info from user space to ASoC framework and generate different audio components for the sound card.<br /> <br /> == '''Topology Objects''' ==<br /> <br /> Topology objects can be loaded from the user space include controls, widgets, routes, PCMs and configurations for physical DAI &amp; DAI links.<br /> Please check alsa-lib include/topology.h, which include the syntax for all supported objects.<br /> <br /> Here is an example.<br /> <br /> [[File:Topology-objects.png]]<br /> <br /> == '''How to generate topology info in user space''' ==<br /> TBD<br /> <br /> == '''How device drivers use topology ''' ==<br /> TBD</div>

Mengdonglin https://www.alsa-project.org/main/index.php?title=ALSA_topology&diff=7173 2016-11-10T01:08:31Z

<p>Mengdonglin: /* Topology Objects */</p> <hr /> <div>ALSA Topology provides a method for audio drivers to load their mixers, routing, PCMs and capabilities from user space at runtime without changing any driver source code. The intention is to write the driver once and do the differentiation in topology.<br /> <br /> == '''Why we need topology?''' ==<br /> <br /> Current audio drivers typically hard code topology information in the driver sources:<br /> This tightly couples the audio driver to the development board making it time consuming to modify a driver to work on a different devices. <br /> The driver is also tightly coupled to the DSP firmware version meaning extra care is needed to keep the driver and firmware version in sync. New firmware features also mean driver updates.<br /> <br /> The ALSA topology project removes the need for re-writing or porting audio drivers to different devices or different firmwares:<br /> Drivers have no hard coded topology data meaning a single driver can be used on different devices by updating the topology data from the file system. <br /> Firmware updates can be pushed without having to update the drivers. The new firmware just needs to include an updated topology file describing the update.<br /> <br /> == '''Topology Architecture''' ==<br /> <br /> [[File:Topology.png]]<br /> <br /> === User space ===<br /> Provide a tool &amp; library to generate a binary file that describes the internal topology of a customer firmware, e.g. for an ADSP in SOC or 3rd party codec. Please check source files of alsa-lib in directory src/topology.<br /> <br /> === Kernel === <br /> Provide generic support to import the topology info from user space to ASoC framework and generate different audio components for the sound card.<br /> <br /> == '''Topology Objects''' ==<br /> <br /> Topology objects can be loaded from the user space include controls, widgets, routes, PCMs and configurations for physical DAI &amp; DAI links.<br /> Please check alsa-lib include/topology.h, which include the syntax for all supported objects.<br /> <br /> Here is an example.<br /> <br /> [[File:Topology-objects.png]]</div>

Mengdonglin https://www.alsa-project.org/main/index.php?title=ALSA_topology&diff=7172 2016-11-10T01:04:14Z

<p>Mengdonglin: </p> <hr /> <div>ALSA Topology provides a method for audio drivers to load their mixers, routing, PCMs and capabilities from user space at runtime without changing any driver source code. The intention is to write the driver once and do the differentiation in topology.<br /> <br /> == '''Why we need topology?''' ==<br /> <br /> Current audio drivers typically hard code topology information in the driver sources:<br /> This tightly couples the audio driver to the development board making it time consuming to modify a driver to work on a different devices. <br /> The driver is also tightly coupled to the DSP firmware version meaning extra care is needed to keep the driver and firmware version in sync. New firmware features also mean driver updates.<br /> <br /> The ALSA topology project removes the need for re-writing or porting audio drivers to different devices or different firmwares:<br /> Drivers have no hard coded topology data meaning a single driver can be used on different devices by updating the topology data from the file system. <br /> Firmware updates can be pushed without having to update the drivers. The new firmware just needs to include an updated topology file describing the update.<br /> <br /> == '''Topology Architecture''' ==<br /> <br /> [[File:Topology.png]]<br /> <br /> === User space ===<br /> Provide a tool &amp; library to generate a binary file that describes the internal topology of a customer firmware, e.g. for an ADSP in SOC or 3rd party codec. Please check source files of alsa-lib in directory src/topology.<br /> <br /> === Kernel === <br /> Provide generic support to import the topology info from user space to ASoC framework and generate different audio components for the sound card.<br /> <br /> == '''Topology Objects''' ==<br /> <br /> Topology objects can be loaded from the user space include controls, widgets, routes, PCMs and configurations for physical DAI &amp; DAI links,<br /> <br /> [[File:Topology-objects.png]]</div>

Mengdonglin https://www.alsa-project.org/main/index.php?title=File:Topology-objects.png&diff=7171 2016-11-10T00:58:38Z

<p>Mengdonglin: </p> <hr /> <div></div>

Mengdonglin https://www.alsa-project.org/main/index.php?title=ALSA_topology&diff=7170 2016-11-07T16:28:45Z

<p>Mengdonglin: /* Topology Architecture */</p> <hr /> <div>ALSA Topology provides a method for audio drivers to load their mixers, routing, PCMs and capabilities from user space at runtime without changing any driver source code. The intention is to write the driver once and do the differentiation in topology.<br /> <br /> == '''Why we need topology?''' ==<br /> <br /> Current audio drivers typically hard code topology information in the driver sources:<br /> This tightly couples the audio driver to the development board making it time consuming to modify a driver to work on a different devices. <br /> The driver is also tightly coupled to the DSP firmware version meaning extra care is needed to keep the driver and firmware version in sync. New firmware features also mean driver updates.<br /> <br /> The ALSA topology project removes the need for re-writing or porting audio drivers to different devices or different firmwares:<br /> Drivers have no hard coded topology data meaning a single driver can be used on different devices by updating the topology data from the file system. <br /> Firmware updates can be pushed without having to update the drivers. The new firmware just needs to include an updated topology file describing the update.<br /> <br /> == '''Topology Architecture''' ==<br /> <br /> [[File:Topology.png]]<br /> <br /> === User space ===<br /> Provide a tool &amp; library to generate a binary file that describes the internal topology of a customer firmware, e.g. for an ADSP in SOC or 3rd party codec. Please check source files of alsa-lib in directory src/topology.<br /> <br /> === Kernel === <br /> Provide generic support to import the topology info from user space to ASoC framework and generate different audio components for the sound card.</div>

Mengdonglin https://www.alsa-project.org/main/index.php?title=ALSA_topology&diff=7169 2016-11-05T17:44:31Z

<p>Mengdonglin: </p> <hr /> <div>ALSA Topology provides a method for audio drivers to load their mixers, routing, PCMs and capabilities from user space at runtime without changing any driver source code. The intention is to write the driver once and do the differentiation in topology.<br /> <br /> == '''Why we need topology?''' ==<br /> <br /> Current audio drivers typically hard code topology information in the driver sources:<br /> This tightly couples the audio driver to the development board making it time consuming to modify a driver to work on a different devices. <br /> The driver is also tightly coupled to the DSP firmware version meaning extra care is needed to keep the driver and firmware version in sync. New firmware features also mean driver updates.<br /> <br /> The ALSA topology project removes the need for re-writing or porting audio drivers to different devices or different firmwares:<br /> Drivers have no hard coded topology data meaning a single driver can be used on different devices by updating the topology data from the file system. <br /> Firmware updates can be pushed without having to update the drivers. The new firmware just needs to include an updated topology file describing the update.<br /> <br /> == '''Topology Architecture''' ==<br /> <br /> [[File:Topology.png]]</div>

Mengdonglin https://www.alsa-project.org/main/index.php?title=ALSA_topology&diff=7168 2016-11-05T17:41:06Z

<p>Mengdonglin: /* Why we need topology? */</p> <hr /> <div>Topology can help users to configure Audio DSP firmware topology at runtime. The audio DSP can be either embedded in SoC or codec chips. Now it's only for ASoC, and may be extended for ALSA.<br /> <br /> == '''Why we need topology?''' ==<br /> <br /> Current audio drivers typically hard code topology information in the driver sources:<br /> This tightly couples the audio driver to the development board making it time consuming to modify a driver to work on a different devices. <br /> The driver is also tightly coupled to the DSP firmware version meaning extra care is needed to keep the driver and firmware version in sync. New firmware features also mean driver updates.<br /> <br /> The ALSA topology project removes the need for re-writing or porting audio drivers to different devices or different firmwares:<br /> Drivers have no hard coded topology data meaning a single driver can be used on different devices by updating the topology data from the file system. <br /> Firmware updates can be pushed without having to update the drivers. The new firmware just needs to include an updated topology file describing the update.<br /> <br /> == '''Topology Architecture''' ==<br /> <br /> [[File:Topology.png]]</div>

Mengdonglin https://www.alsa-project.org/main/index.php?title=ALSA_topology&diff=7167 2016-11-05T17:38:49Z

<p>Mengdonglin: /* Topology Architecture */</p> <hr /> <div>Topology can help users to configure Audio DSP firmware topology at runtime. The audio DSP can be either embedded in SoC or codec chips. Now it's only for ASoC, and may be extended for ALSA.<br /> <br /> == '''Why we need topology?''' ==<br /> <br /> Current audio drivers typically hard code topology information in the driver sources:<br /> This tightly couples the audio driver to the development board making it time consuming to modify a driver to work on a different device. <br /> The driver is also tightly coupled to the DSP firmware version meaning extra care is needed to keep the driver and firmware version in sync. New firmware features also mean driver updates.<br /> <br /> The ASoC topology (DFW) project removes the need for re-writing or porting audio drivers to different devices or different firmwares:<br /> Drivers have no hard coded topology data meaning a single driver can be used on different devices by updating the topology data from the file system. <br /> Firmware updates can be pushed without having to update the drivers. The new firmware just needs to include an updated topology file describing the update.<br /> <br /> == '''Topology Architecture''' ==<br /> <br /> [[File:Topology.png]]</div>

Mengdonglin https://www.alsa-project.org/main/index.php?title=File:Topology.png&diff=7166 2016-11-05T17:37:11Z

<p>Mengdonglin: </p> <hr /> <div></div>

Mengdonglin https://www.alsa-project.org/main/index.php?title=ALSA_topology&diff=7165 2016-11-05T17:35:15Z

<p>Mengdonglin: /* Why we need topology? */</p> <hr /> <div>Topology can help users to configure Audio DSP firmware topology at runtime. The audio DSP can be either embedded in SoC or codec chips. Now it's only for ASoC, and may be extended for ALSA.<br /> <br /> == '''Why we need topology?''' ==<br /> <br /> Current audio drivers typically hard code topology information in the driver sources:<br /> This tightly couples the audio driver to the development board making it time consuming to modify a driver to work on a different device. <br /> The driver is also tightly coupled to the DSP firmware version meaning extra care is needed to keep the driver and firmware version in sync. New firmware features also mean driver updates.<br /> <br /> The ASoC topology (DFW) project removes the need for re-writing or porting audio drivers to different devices or different firmwares:<br /> Drivers have no hard coded topology data meaning a single driver can be used on different devices by updating the topology data from the file system. <br /> Firmware updates can be pushed without having to update the drivers. The new firmware just needs to include an updated topology file describing the update.<br /> <br /> == '''Topology Architecture''' ==</div>

Mengdonglin https://www.alsa-project.org/main/index.php?title=ALSA_topology&diff=7164 2016-11-05T17:34:44Z

<p>Mengdonglin: </p> <hr /> <div>Topology can help users to configure Audio DSP firmware topology at runtime. The audio DSP can be either embedded in SoC or codec chips. Now it's only for ASoC, and may be extended for ALSA.<br /> <br /> == '''Why we need topology?''' ==<br /> <br /> Current audio drivers typically hard code topology information in the driver sources:<br /> This tightly couples the audio driver to the development board making it time consuming to modify a driver to work on a different device. <br /> The driver is also tightly coupled to the DSP firmware version meaning extra care is needed to keep the driver and firmware version in sync. New firmware features also mean driver updates.<br /> <br /> The ASoC topology (DFW) project removes the need for re-writing or porting audio drivers to different devices or different firmwares:<br /> Drivers have no hard coded topology data meaning a single driver can be used on different devices by updating the topology data from the file system. <br /> Firmware updates can be pushed without having to update the drivers. The new firmware just needs to include an updated topology file describing the update.</div>

Mengdonglin https://www.alsa-project.org/main/index.php?title=ALSA_topology&diff=7163 2016-11-05T17:33:12Z

<p>Mengdonglin: /* ALSA Topology */</p> <hr /> <div>Topology allows users to configure Audio DSP firmware topology at runtime. The audio DSP can be either embedded in SoC or codec chips. Now it's major for ASoC, and maybe extended for ALSA.<br /> <br /> == '''Why we need topology?''' ==<br /> <br /> Current audio drivers typically hard code topology information in the driver sources:<br /> This tightly couples the audio driver to the development board making it time consuming to modify a driver to work on a different device. <br /> The driver is also tightly coupled to the DSP firmware version meaning extra care is needed to keep the driver and firmware version in sync. New firmware features also mean driver updates.<br /> <br /> The ASoC topology (DFW) project removes the need for re-writing or porting audio drivers to different devices or different firmwares:<br /> Drivers have no hard coded topology data meaning a single driver can be used on different devices by updating the topology data from the file system. <br /> Firmware updates can be pushed without having to update the drivers. The new firmware just needs to include an updated topology file describing the update.</div>

Mengdonglin https://www.alsa-project.org/main/index.php?title=ALSA_topology&diff=7162 2016-11-05T17:32:37Z

<p>Mengdonglin: Created page with &quot;== '''ALSA Topology''' == Topology allows users to configure Audio DSP firmware topology at runtime. The audio DSP can be either embedded in SoC or codec chips. Now it's majo...&quot;</p> <hr /> <div>== '''ALSA Topology''' ==<br /> <br /> Topology allows users to configure Audio DSP firmware topology at runtime. The audio DSP can be either embedded in SoC or codec chips. Now it's major for ASoC, and maybe extended for ALSA.<br /> <br /> Why we need topology?<br /> <br /> Current audio drivers typically hard code topology information in the driver sources:<br /> This tightly couples the audio driver to the development board making it time consuming to modify a driver to work on a different device. <br /> The driver is also tightly coupled to the DSP firmware version meaning extra care is needed to keep the driver and firmware version in sync. New firmware features also mean driver updates.<br /> <br /> The ASoC topology (DFW) project removes the need for re-writing or porting audio drivers to different devices or different firmwares:<br /> Drivers have no hard coded topology data meaning a single driver can be used on different devices by updating the topology data from the file system. <br /> Firmware updates can be pushed without having to update the drivers. The new firmware just needs to include an updated topology file describing the update.</div>

Mengdonglin https://www.alsa-project.org/main/index.php?title=Developer_Zone&diff=7161 2016-11-05T17:23:05Z

<p>Mengdonglin: /* Zone for ALSA developers */</p> <hr /> <div>==Zone for ALSA developers==<br /> <br /> * [[ApplicationDevelopment]] - Technical Info to aid application developers.<br /> * [[ALSA_Driver_Documentation]] - Info to aid driver developers.<br /> * [[DriversInDevelopment]] - Technical Info on various drivers in development<br /> * [[DevelAPI]] - discussions/proposals/prototypes about API changes, extensions, new API design etc.<br /> * [[GIT_Server]] - How to use the new git repository.<br /> * [http://git.alsa-project.org/ Online GIT Repository]<br /> * [[:Category:DevToDoLists]] - Developers with TODO lists.<br /> * [[DevEmbedded]] - How to build ALSA for embedded applications.<br /> * [[ASoC]] - ALSA for System on Chip processors.<br /> * [[DAPM]] - Dynamic Audio Power Management.<br /> * [[http://alsa-project.org/~james/ James's development area]]<br /> * [[Scenario]] - ALSA scenario / use case API (in progress).<br /> * [[Conferences]] - ALSA conferences.<br /> * [[BAT]] - Basic Audio Tester util.<br /> * [[Firmware]] - Sound Open Firmware.<br /> * [[ALSA topology]] - Technical information for generating runtime topologies.<br /> <br /> [[PCM Ring Buffer|Some Details about PCM Ring Buffer]].<br /> <br /> ==Migration from dev wiki==<br /> ===TODO===<br /> * https://bugtrack.alsa-project.org/wiki/wikka.php?wakka=JamesCourtierDutton only some questions?<br /> * https://bugtrack.alsa-project.org/wiki/wikka.php?wakka=jcdutton JCD todo list<br /> * https://bugtrack.alsa-project.org/wiki/wikka.php?wakka=LiamGirdwood todo list<br /> * Pages linked from [[DriversInDevelopment]]<br /> <br /> ===Won't do?===<br /> * https://bugtrack.alsa-project.org/wiki/wikka.php?wakka=Audigy empty<br /> * https://bugtrack.alsa-project.org/wiki/wikka.php?wakka=Audigy4 empty except link to capture info<br /> * https://bugtrack.alsa-project.org/wiki/wikka.php?wakka=KelNat empty<br /> * https://bugtrack.alsa-project.org/wiki/wikka.php?wakka=MidiQuest historical, inconclusive<br /> * https://bugtrack.alsa-project.org/wiki/wikka.php?wakka=MultipleCards Q&amp;A on card indexing belongs elsewhere?<br /> * https://bugtrack.alsa-project.org/wiki/wikka.php?wakka=NormanSchleicher Empty, will be [[User:NormanSchleicher]] on this wiki<br /> * TroubleShooting - No sound? System panics? Look here for help! ''?Doesn't belong in developer category?'' seems to be very similar to [[alsawiki:TroubleShooting|unofficial wiki TroubleShooting guide]]<br /> <br /> [[Category:Development]] [[Category:MigratedFromDev]]</div>

Mengdonglin