ALSA topology: Difference between revisions
Mengdonglin (talk | contribs) No edit summary |
Mengdonglin (talk | contribs) |
||
| Line 10: | Line 10: | ||
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. | 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. | ||
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. | 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. | ||
== '''Topology Architecture''' == | |||
Revision as of 17:35, 5 November 2016
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.
Why we need topology?
Current audio drivers typically hard code topology information in the driver sources: This tightly couples the audio driver to the development board making it time consuming to modify a driver to work on a different device. 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.
The ASoC topology (DFW) project removes the need for re-writing or porting audio drivers to different devices or different firmwares: 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. 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.