The NVIDIA® Tegra® ASoC driver is implemented for the Android and Linux operating systems and is intended to work seamlessly with different Tegra devices, using an existing framework called Advanced Linux Sound Architecture (ALSA), which is maintained by the upstream Linux community.

This topic describes hardware functionality present on Tegra X2 and Jetson TX2. Hardware functionality may not be supported by the software. Review your software documentation to determine availability of software for audio features.

On Jetson TX2, audio output is supported using HDMI audio. Audio input hardware in the development kit is NOT supported.

The ALSA framework is a part of the Linux kernel that is supported and maintained by the larger Linux community. This makes it feasible to adapt to the framework, designing a driver that leverages NVIDIA audio routing support. ALSA has a very good collection of sound card drivers, including actual codec drivers for platform ADC and DAC support, and can support adding new codec drivers as well.

ALSA also includes libraries and utilities that enable more refined audio control in Linux and Android user space. These include alsamixer, aplay, arecord, tinycap, and others. This enables you to control audio applications without having to interact with kernel space drivers.

The ALSA software hierarchy is as follows.

User space ALSA applications interact with ALSA core (kernel space) through APIs provided by userspace libraries that initialize the actual hardware codecs at the back end of the audio pipeline.

More information on the ALSA framework is available at the following link:

ALSA is designed to support various functionalities including but not limited to dynamic audio routing to the available PCM devices. The component of ALSA core that provides this support is Dynamic Audio Power Management (DAPM). DAPM controls the power flow into and out of various codec blocks in the audio subsystem, thereby minimizing power consumption. DAPM introduces switches or kernel controls in the form of widgets to turn ON/OFF the power of a module and help manipulate the required bit of the specific register dynamically using user space applications such as aplay, arecord, or alsamixer. The widgets are classified into various groups.

More information on the widgets and their applications is available at:

In terms of software hierarchy, DAPM is part of the ALSA core as shown in the Tegra ASoC Driver Overview diagram, helping to manage the codec module power efficiently.

For details on the clocking and power management in Tegra ASoC driver, see Clocking and Power Management topic.

For more information see the Dynamic Audio Routing topic.

The Device Tree is a data structure which describes devices on the platform. It is passed to the operating system at boot time and allows you to avoid hard coding component details in the operating system. In this way it makes it easier to change hardware configurations without rebuilding the kernel.

The data structure contains the name of nodes and properties. Each node can have properties or child nodes, and each property is comprised of a name and more than one value. Device Tree structures must be written in the correct format and according to format rules so that the data structure can be parsed by the operating system.

More details on usage of DTS and its script format can be found at:

For a simple device tree example see the Codec Driver Instantiation via Device Tree section of this chapter.

The Tegra Audio Driver leverages Tegra Audio Hub (AHUB) hardware acceleration in the form of platform and codec drivers. The ARM peripheral bus interface (ADMAIF) is implemented as a platform driver with PCM interfaces for playback/record and the rest of the AHUB modules such as the Audio Cross Bar (XBAR), Audio Multiplexer (AMX), Audio Demultiplexer (ADX) and Inter-IC sound (I2S) implemented as codec drivers. Each of the drivers is connected to XBAR through Digital Audio Interfaces (DAIs), inside a machine driver, forming an audio hub.

The machine driver probe instantiates the sound card device and registers all the PCM interfaces as exposed by ADMAIF. After booting, before we can use these interfaces to playback or record audio, you must set up the audio paths inside XBAR. By default, XBAR has no routing connections at boot, and no DAPM path is complete to power on the corresponding widgets. The XBAR driver introduces MUX widgets for all the audio components and enables you to create any custom routing through kcontrol from user space using the alsamixer utility. If the audio path is not complete, the DAPM path is not closed. Hardware settings are not applied and you might not hear any audio output.

For more details on how to set up the route and how to play or record on the PCM interfaces, see the Audio Playback/Record Examples section of this document.

The Tegra audio hub architecture is as follows:

The audio hub contains the modules I2S, SPDIF, and the Digital MIC Controller (DMIC) that interface with the external world. The audio hub also contains Mixer, Sampling Frequency Converter (SFC), Master Volume Control (MVC), Output Processing Engine (OPE), Audio Multiplexers (AMX), Audio Demultiplexers (ADX) and Audio Flow Controllers (AFC). An Audio Direct Memory Access (ADMA) component is included (ADMAIF-DMA) to communicate with memory. The Crossbar (XBAR) facilitates the routing of audio samples through these modules using a proprietary protocol called Audio Client Interface (ACIF).

The modules in the audio hub support various kinds of audio devices that are expected to interface with the application processor, such as cellular baseband devices, different types of audio CODECs, Bluetooth modules, and A/V receivers. The audio hub is capable of supporting the different interface and signal quality requirements of these devices.

Each of the AHUB modules has at least one RX port and one TX port, and some have more than one, depending on whether they are for duplex flow such as I2S. The RX ports feed off from XBAR and the TX ports are fed back into XBAR, except in the case of I2S where one end feeds of the actual codec. This configuration makes XBAR a switch where an audio input can be fed to multiple outputs depending on use case.

For dynamic audio routing examples see the Audio Playback/Record Examples topic.

Each ADMAIF has both TX and RX FIFOs that support simultaneous recording and playback. ADMA transfers the data to the ADMAIF FIFO for all audio routing scenarios.

For details on hardware configuration of each module, refer to the Tegra Reference Manual.

The software architecture of the Tegra ASoC driver is very similar to the hardware architecture of the AHUB. This enables you to leverage all the features supported by the hardware and still conform to the ALSA framework. This ALSA System on a Chip (ASoC) driver is comprised of platform, codec and machine drivers.

For details on how to write a machine driver and identify a sound card, see the Tegra Machine Driver topic and the kernel documentation for AsoC framework at:

The Tegra platform driver realizes the number of ports of playback and capture possible inside the AHUB. Some or all of these ports can connected to form a full audio routing path. You must complete these paths as described in Audio Playback/Record Examples.

In the Tegra ASoC driver, ADMAIF is implemented as a platform driver and interfaces with the PCM driver. The PCM driver helps perform DMA operations by overriding the function pointers exposed by the snd_pcm_ops structure. The PCM driver is platform agnostic and interacts only with the SOC DMA engine upstream APIs. The DMA engine then interacts with the platform specific DMA driver to get the correct DMA settings. The ADMAIF platform driver defines DAIs and registers the same with ASoC core.

In Tegra X2, there are 10 ADMAIFs. Each ADMAIF is bi-directional, facilitating 10 streams of playback and 10 streams of capture.

A small overview of codec drivers is presented in the Tegra Audio Hub section of this document. In the Tegra ASoC driver implementation, the rest of the AHUB modules, except ADMAIF, are implemented as codec drivers.

Their responsibilities include:

The XBAR codec driver defines RX, TX and MUX widgets for all the interfacing modules such as ADMAIF, AMX, ADX, I2S, SPDIF, DMIC, Mixer, SFC, MVC, OPE and AFC. MUX widgets are permanently routed to the corresponding TX widgets inside the snd_soc_dapm_route structure.

However, the XBAR interconnections are made by connecting any RX widget block to any MUX widget block as needed using the alsamixer utility. The get/put handlers for these widgets are implemented so that audio connections are stored by setting the appropriate bit in the hardware MUX register.

For more information see the Audio Playback/Record Examples topic and the Dynamic Audio Routing topic.

An Audio Multiplexer (AMX) module can multiplex up to 4 streams of 16 channels, 32 bits each, into one time-division multiplexed (TDM) stream of 16 channels and 32 bits. The 4 RX ports of AMX originate from XBAR and 1 TX port feeds into XBAR. The DAPM widgets exposed are as shown in the following diagram. The DAPM routes established using these widgets are shown in the dotted lines.

The AMX Codec Driver Internals are as follows:

An Audio Demultiplexer (ADX) module can de-multiplex a single TDM stream of 16 channels and 32 bits into 4 streams of up to 16 channels, 32 bits each. The 1 RX port of ADX originates from XBAR and 4 TX ports feeds into XBAR. The DAPM widgets exposed are as shown in the following diagram. The DAPM routes established using these widgets are shown in the dotted lines.

The ADX Codec Driver Internals is as follows:

An I2S module supports 6 different modes, the most useful of which are I2S and TDM. When I2S is configured in TDM mode, we can use AMX and ADX for multiplexing and demultiplexing audio streams. I2S module can also be in I2S mode if the physical codec interfaced does not support TDM mode of operation. An I2S codec driver supports bidirectional data flow and thus defines CIF and DAP RX/TX widgets as shown in the following diagram. The CIF side of I2S, interfaces with XBAR and DAP side is meant to interface with the physical codec on the given platform. The DAPM routes established using these widgets are shown in the dotted lines. I2S modules also expose kernel control to enable internal I2S loopback.

The I2S Codec Driver Internals is as follows:

The Mixer can mix audio streams from any of the 10 XBAR-originating input ports to any of the 5 output ports. The DAPM widgets and routes for Mixer are shown in the following diagram. The Mixer driver also exposes Rx Gain and Mixer Enable as additional kcontrols to set the volume of each input stream and to globally enable or disable the Mixer itself.

The Mixer Codec Driver Internals is as follows:

The Sampling Frequency Converter(SFC) can convert the input sampling frequency to the required sampling rate. SFC has one input port and one output port which are connected to XBAR. The DAPM widgets and routes for SFC are as follows:

The SPDIF driver is very similar to I2S in terms of the DAPM widgets that are exposed and the routing setup. SPDIF is also bidirectional and adapts to the sampling rate of the incoming data. It is implemented as follows:

It is beneficial to interface directly to digital microphones and speakers via pulse-density modulation (PDM), thus avoiding the need for a PDM-capable external codec. The DMIC controller implements a converter to convert PDM (Pulse density modulation) signals to PCM (Pulse code modulation) signals. The DAPM widgets and routes are as follows.

MVC provides gain or attenuation to a digital signal path. The digital volume control block is a generic block. It can be used in input or output digital signal path. It can also be used for per-stream volume control and master volume control. The DAPM widgets and routes as follows.

The Output Processing Engine (OPE) is a client of AHUB. OPE contains PEQ and MBDRC which have a scalable number of BiQuad stages, support stereo, 5p1 and 7p1 channels, and meet ultra-low power(ULP) audio requirements. The DAPM widgets and routes are as follows.

The Tegra machine driver connects the codec drivers by linking the DAIs exposed by each module described in previous chapter. It defines the snd_soc_dai_link structure and instantiates the sound card.

In general, machine driver responsibilities include:

To adapt the generic machine driver template to a given platform, you must initialize the platform data structure in the device tree structure file shown below. It is important to gather some information about the hardware platform. You must identify the physical codecs present on board and the I2S instance they interface with in the hardware. Refer to hardware schematics for the platform to obtain this information.

The sound node is added to the DT file for sound card registration and passing platform related data. To bind a device driver to a specific device in a DT file, each node must define a compatible property, which is a list of strings. The optional nvidia,model property is used for the sound card name. The nvidia,num-codec-link property shows the number of dai links exposed outside of the Tegra devices such as I2S, SPDIF or DMIC. This is the same as the number of nvidia,dai-link-<number> child nodes.

In Tegra X2 devices, each AMX and ADX has two modules, nvidia,num-amx and nvidia,num-adx. These indicate the total number of AMX and ADX to be registered by the machine driver. The nvidia,amx-slot-size and nvidia,adx-slot-size properties indicate the slot map size of each module, which is related to the size of nvidia,amx-slot-map and nvidia,adx-slot-map. The machine driver uses the default value for each property to support stereo 16 bits while initiating AMX and ADX modules unless the above properties are overridden.

The nvidia,dai-link-<number> node is initialized based on I2S and physical codec links as shown above. You can replace the codec with a dummy spdif-dit.0 codec. In that case, you must program the physical codecs at the required sampling rate and operational modes either through a separate utility or by adding necessary hw_params API calls inside the machine driver. The link-name property represents each DAI link, and differentiates the codecs connected to the different I2S instances.

The bitclock-slave, frame-slave, format, bitclock-noninverstion and frame-noninversion properties set I2S in I2S/TDM formats and/or master/slave modes. The bclk-ratio property is available to configure the I2S bit clock sample rate. The srate and num-channel properties indicate I2S LRCK and the number of channels in one frame. DAPM routes are initialized as established in nvidia,audio-routing property.

In the Tegra X2 combination of boards, there is one available AD1937s codec. AD1937 supports eight channels in TDM and I2S modes, respectively. The AD1937 codec is connected to I2S4 on P1892.

The platform data structure must be initialized in the DT file so that the machine driver can retrieve the device specific information during the platform probe. The DAI link diagram for PEDP+ with Tegra X2, where the left side of each DAI is CPU DAI, and right side of each DAI is codec DAI in snd_soc_dai_link, is as follows.

The dai_fmt sets I2S4 in TDM master mode. It also connects codec AD1937 with I2S4 DAPM routes and AMX/ADX slot maps initialized. The sound card is named tegra-snd-t210ref.

The DAPM widgets supported in the generic machine driver include Headphone-x, Headphone-y, Headphone-z, Headphone-s, LineIn-x, LineIn-y, LineIn-z, and LineIn-s. Based on how name_prefix and dai_fmt are initialized, the DAPM route must be set by parsing the IN/OUT DAPM widgets of the physical codec. Without this, the DAPM path is not complete and audio does not function correctly. The Tegra X2 audio map is shown below.

Though we can assign any ADMAIF to any AMX via XBAR, we can fix ADMAIF1 to ADMAIF4 as the inputs of AMX1 are connected to I2S4.

The machine driver creates three snd_soc_dai_links for each dai-link-<number> node initialized in the DT file and appends them to XBAR DAI links using the utility API. It also initializes the .dai_ops for the ADMAIF interfaces accordingly as shown below.

The dai_link connection in the machine driver only connects the platform and codec drivers to XBAR driver. However, to realize any audio output from the physical codecs, you must complete the DAPM path by routing through the internals of XBAR, i.e., connect the RX and MUX widgets.from user space using alsamixer utility as follows.

Instantiation of the sound card after boot indicates that all codec drivers and the platform driver are interconnected using the machine driver. The remaining step before obtaining the audio output on the physical codecs involves routing through the XBAR internals via MUX widgets to complete the DAPM path using the alsamixer utility. To support audio routing dynamically between AHUB modules, this route setting step is performed from user space. This provides flexibility for complicated use cases.

For example, [amixer -c 0 sset ‘I2S1 Mux’ ‘I2S1’] realizes the internal AHUB path I2S1 RX -> XBAR -> I2S1 TX. Similarly, the following are use cases that emphasize dynamic audio route control from user space.

Path: I2S -> ADX -> AMX -> I2S

Commands:

Path: [I2S -> ADX -> AMX -> I2S] + [I2S3 -> AMX -> I2S4]

Initially audio records from I2S4 and outputs on I2S4.

Commands:

After this step, audio records from I2S3 and outputs on I2S4

Based on architecture, the Makefile in the following directory conditionally compiles the required DTS files into DTB files:

When the kernel is flashed, the flash script chooses the required DTS file for parsing during boot, and the ASoC codecs listed in DTS are instantiated. To add any new module instantiation as a requirement, identify and edit the Device Tree script as reported in the dmesg log on the target as shown in the following example:

The Tegra X2 AHUB consists of 2 hardware audio multiplexers (AMX) and demultiplexers (ADX) as described in Tegra Audio Hub. Initialize slot mapping in the platform data as shown in Machine Specific DAI links. Without any initialization, the machine driver defaults the slot map for AMX inputs and ADX outputs at 16-bit stereo and 8-channel, 32 bit TDM output. To change the slot mapping of hardware TDMs, adjust the slot map structures in the DT file.

The AMX can multiplex up to 4 input streams, each of which can be up to 16 channels, 32 bits, into 1 single output stream of 16 channels, 32 bits to form a TDM signal. The capability of ADX is the reverse of AMX.

The slot map is an integer array of size 32 that controls the mapping of these input streams to the output stream. The following macro is available:

where stream_id can vary from 0 to 3, nth_channel can vary from 1 to 16, and nth_byte can vary from 0 to 3.

The clock tree of the Tegra ASoC driver in the idle state, when no audio record or playback is in progress, is as shown below.

The clocks of the individual modules, AMX, ADX, AFC, SFC, MIXER, and others, are internally handled by the APE clock. The clock for the codec drivers I2S and XBAR are switched OFF in idle. They are turned ON when audio playback or recording is in progress. The idle_bias_off option provided by ASoC core (snd_soc_codec_driver) is set to 1 in the individual codec drivers for dynamic audio power management. With this option, the ASoC core calls the appropriate resume() and suspend() functions in the codec driver that was registered using SET_RUNTIME_PM_OPS during platform probe.

The suspend and resume APIs are called when playback or record stops or starts. The suspend API caches the register map and disables the clock. The resume API enables the clock and then syncs the register map from the cache.

To test audio playback and record scenarios, make sure the XBAR route is set up using alsamixer commands, based on the platform. The following provides the sample testing commands for audio playback and record scenarios.

In this case, “DAP” is the CPU DAI for the I2S to codec dai link. The I2S codec may not be instantiated in ASoC. Confirm that with the following command:

if tegra30-i2s is instantiated.

Identification of the DAI link at the point of failure would give a clue on the I2S instance number that failed to instantiate. Accordingly, the I2S codec driver can be instantiated by providing a suitable entry point in DTS file as described in Codec Driver Instantiation via Device Tree.

If I2S-x and I2S-y are under the same clock domain for the sake of case study, AFC1 insertion between ADX1-1 and AMX1-4 does not help. However, the audio routing path can still be constructed as follows.