ASoC Driver in Jeston TX1 and TX2

From RidgeRun Developer Wiki




Problems running the pipelines shown on this page? Please see our GStreamer Debugging guide for help.


Driver List Information
Refer to the RidgeRun Linux Camera Drivers to meet all the list of Drivers available


Introduction to NVIDIA®Jetson™ TX1 TX2 audio subsystem

This wiki page shows an overview of the Jetson TX1 and Jetson TX2 audio subsystem and the ASoC driver. This wiki doesn't pretend to be a comprehensive guide but instead a quick introduction about how to start writing an audio driver for the platform. Most of this documentation is based on the Tegra Linux Driver Package Development Guide 24.1 Release therefore we are going to discuss only the most important sections.

In the first section, you are going to find an overview of the hardware architecture, followed by the software structure to finish with a quick example of an audio driver.

Jetson TX1 TX2 audio subsystem based in TRM chapter 23

The audio processing engine (APE) in Tegra ® X1 mobile processors takes care of all the audio needs of Tegra chips with minimal supervision from the CPU. The APE contains an audio DSP (ADSP), an internal RAM, an “Audio Hub” or HUB containing many hardware accelerators, and a DMA engine as shown below. The AHUB has external I2S, S/PDIF, and DMIC interfaces. The AHUB supports multiple interfaces to the audio devices in the system cellular baseband, different audio codecs, Bluetooth modules; A/V receivers, etc. The AHUB can support the different interfaces, protocols, and signal quality requirements of these audio devices.

The audio processing engine (APE) provides the following interfaces:

  • APB Interface
  • Audio Interfaces:
    • I2S x 5
    • SPDIF x1
    • DMIC x 3
  • Interrupts
    • IRQCPU, FIQCPU – Interrupts to CPU
  • Debug Port
    • CoreSightTM interface to ADSP
    • UART (no DMA engine)
  • Clocks
    • MC_CLK
    • PCLK (apb_clock)
    • APE_CLK
    • ADSP_CLK
  • Resets
    • APE_reset
    • ADSP_reset
    • PCLK
  • Memory Interface
  • External Signaling
    • 56-bit grayscale TSC signals

APE 1.0 consists of the following modules:

  • ADSP includes the ARM-based CPU and its cache
  • AHUB contains the audio hardware accelerators. It also interfaces with audio I/O
  • ADMA is responsible for moving data between AHUB and DRAM/ARAM
  • REGDEC serves as the register interface for ADMA and AHUB
  • ACONNECT is an AXI based backbone that directs requests from different masters to targeted slaves
  • AMC is the local memory controller for local memory residing in this module
  • ABRIDGE is the memory interface to DRAM
  • AGIC is the interrupt controller
  • AMISC contains the configuration registers and synchronizations registers
  • AAS converts APB transactions from CPU to AXI transactions

Audio AHUB

The audio Hub (AHUB) is a collection of hardware accelerators with a means for audio data to be routed through these accelerators. The purpose of AHUB is to offload repetitive tasks that do not need constant decision-making from CPU/Audio DSP (ADSP).

The hardware accelerators contained in the AHUB are:

  • Inter-IC Sound Controller (I2S)
  • Digital MIC Controller (DMIC)
  • Sony/Philips Digital Interface Controller (SPDIF)
  • Mixer
  • Audio Multiplexer (AMX)
  • Audio De-Multiplexer (ADX)
  • Sampling Frequency Converter (SFC)
  • Audio Flow Controller (AFC)
  • Output Processing Engine (OPE)
  • Master Volume Control (MVC)
  • Audio Direct Memory Access Interface (ADMA I/F)

A proprietary interface called Audio Client Interface (ACIF) is used to route audio samples through these accelerators. A switch called Audio Crossbar (AXBAR) is used to configure/modify the audio routing path between these accelerators. The accelerator modules and the audio routing are both configured via an AHUB Configuration (AHC) unit.

Here is a block diagram of AHUB:

AHUB block diagram (from TRM)

I2S Controller

The Inter-IC Sound (I2S) controller implements full-duplex and bidirectional and single direction point-to-point serial interfaces. It can interface with I 2 S-compatible products, such as compact disc players, digital audio tape devices, digital sound processors, modems, Bluetooth chips, etc.

The I2S controller can operate both as master and slave. It supports the following data transfer modes:

  • I2S mode
  • Left Justified Mode (LJM)
  • Right Justified Mode (RJM)
  • DSP mode, as defined in the Philips inter-IC-sound (I2S) bus specification
  • PCM mode with short (one-bit-clock wide) and long-fsync (two bit-clocks wide
  • Network (Telephony) mode with independent slot selection for both Tx and Rx
  • TDM mode with flexibility in a number of slots with up to 16 slots.
  • Capability to drive-out a High-Z outside the prescribed slot for transmission

The I2S controller can transmit and receive word lengths of 8, 16, 24, and 32.

Mixer

Mixer Features:

  • Supports mixing up to 10 input streams of 7.1 channel audio each
  • Supports 5 outputs each of which can be a mix of any combination of 10 input streams
  • Time ramp-up/ramp-down volume control provided for each stream
  • Fixed gain for each stream is also available
  • A 32-bit sample counter is provided for each input stream to count the number of samples consumed
  • A peak meter for each input stream is available. It can give peak values for non-overlapping frames of samples or can do continuous reset-on-read peak metering

Audio omultiplexer (AMX)

The Audio Multiplexer Block (AMX) can multiplex up to 4 input streams of up to 16 channels each and generate an output stream of up to 16 channels. A “byte RAM” helps to form an output frame by any combination of bytes from the 4 input frames Two modes for data synchronization between input frames are available:

  • Wait For All mode: At the beginning, wait for all enabled input streams to have data before forming the very first frame.
  • Wait for Any mode: Start whenever data is available in any one of the enabled input streams.

Audio demultiplexer (ADX)

The demultiplexer block (ADX) takes an input stream with up to 16 channels and demultiplexes it into four output streams of up to 16 channels each.

Sampling frequency converter (SFC)

The sampling frequency converter (SFC) converts the sampling frequency of the input signal from one frequency to another.

SFC Features

  • Supports sampling frequency conversion of streams of up to 2 channels (stereo)
  • Has a very low latency with the maximum latency of < 125μs
  • Supports the following frequency conversions

Output processing engine (OPE)

The Output Processing Engine (OPE) is one of the AHUB’s clients and contains audio equalizers.

OPE Features:

  • Scalable Number of BiQuad Stages
  • Supports stereo, 5p1, and 7p1 channels.
  • Meets ultra-low-power(ULP) audio requirements

Master volume control (MVC)

Digital volume control provides gain or attenuation to a digital signal path. The MVC digital volume control block can be used in the input or output digital signal path. It can be used for per-stream volume control as well as a master volume control. The MVC block has one input and one output. The input digital stream can be a mono- or multi-channel (up to 7.1-channels) stream. The output digital stream has the same format as the input stream. The MVC block also has an inbuilt peak meter detector. A Peak meter detector is used as feedback to the user. It is located after volume application and provides the peak output data for each channel. The duration used for the peak meter calculation is programmable.

MVC Features:

  • Programmable range and steps for volume control
  • Programmable Curve Ramp for volume control
  • Independent mute/unmute controls
  • Default gain values
  • Peak meter detector

Pin Muxing

As with most of the SoC, in TX1 each pin can have several functions associated. In this section, the ones related to the I2S interface will be covered. In the case of TX1 we have 5 different I2S ports available:

Source: https://github.com/NVIDIA/tegra-pinmux-scripts/blob/master/configs/tegra210.soc

Audio Interface Ball name Pin GPIO SFIO
AUDIO_MCLK AUD_MCLK F1 GPIO3_PBB.00 aud_mclk
GPIO19/AUD_RST GPIO_X1_AUD F2 GPIO3_PBB.03 xx
GPIO20/AUD_INT GPIO_PE6 H3 GPIO3_PE.06 xx
I2S1_SDIN DAP1_DIN G1 GPIO3_PB.01 I2S1_SDATA_IN
I2S1_SDOUT DAP1_DOUT H2 GPIO3_PB.02 I2S1_SDATA_OUT
I2S1_LRCLK DAP1_FS H1 GPIO3_PB.00 I2S1_LRCK
I2S1_CLK DAP1_SCLK G2 GPIO3_PB.03 I2S1_SCLK
I2S2_SDIN xx G6 GPIO3_PAA.02 I2S2_SDIN
I2S2_SDOUT xx H6 GPIO3_PAA.03 I2S2_SDOUT
I2S2_LRCLK xx H5 GPIO3_PAA.00 I2S2_LRCLK
I2S2_CLK xx G5 GPIO3_PAA.01 I2S2_CLK
I2S3_SDIN DMIC1_DAT G6 GPIO3_PE.01 I2S3_SDIN
I2S3_SDOUT DMIC2_CLK H6 GPIO3_PE.02 I2S3_SDOUT
I2S3_LRCLK DMIC1_CLK H5 GPIO3_PE.00 I2S3_LRCLK
I2S3_CLK DMIC2_DAT G5 GPIO3_PE.03 I2S3_CLK
I2S4A1 uart2_tx B16 GPIO3_PG.00 I2S4A1
I2S4A1 uart2_rx B15 GPIO3_PG.01 I2S4A1
I2S4A1 uart2_rts A16 GPIO3_PG.02 I2S4A1
I2S4A1 uart2_cts A15 GPIO3_PG.03 I2S4A1
I2S4B_LRCLK DAP4_FS F5 GPIO3_PJ.04 xx
I2S4B_SDIN DAP4_DIN E5 GPIO3_PJ.05 xx
I2S4B_SDOUT DAP4_DOUT F6 GPIO3_PJ.06 xx
I2S4B_CLK DAP4_SCLK E6 GPIO3_PJ.07 xx
I2S5A1 dmic3_clk xx GPIO3_PE.04 I2S5A1
I2S5A1 dmic3_dat xx GPIO3_PE.05 I2S5A1
I2S5A1 xx xx GPIO3_PE.06 I2S5A1
I2S5A1 xx xx GPIO3_PE.07 I2S5A1
I2S5B_LRCLK xx D13 GPIO3_PK.00 I2S5B_LRCLK
I2S5B_SDIN xx C14 GPIO3_PK.01 I2S5B_SDIN
I2S5B_SDOUT xx D14 GPIO3_PK.02 I2S5B_SDOUT
I2S5B_CLK xx C15 GPIO3_PK.03 I2S5B_CLK

1 Not sure about the exact pad assignation

Software Overview

Driver example

RidgeRun has the driver for the MAX98357A to handle audio playback. Please send an email to support@ridgerun.com for more technical information.

Connecting the MAX98357A to Jetson TX1

In this case, we have 2 I2S outputs available: I2S1 in J21 and I2S5 in J26, in this case I2S5 will be used so please proceed as follows:

Signal Name MAX98357a JP1 PIN Jetson TX1 J26 PIN
VDD 1 2
GND 2 10
SD_MODE 3 NC
GAIN 4 NC
DIN 5 24
BCLK 6 23
LRCLK 7 26

Audio routing usage and example

All the modules in AHUB can be interconnected depending on our needs. For that purpose, a mixer can be used. The syntax would be as follows:

amixer -c <card number> sset 'SINK PAD' 'SRC PAD'

So lets say we want to connect the output of ADMAIF1 to the input of I2S1 so we can have a direct path from memory to I2S1. The command would be:

amixer -c <card number> sset 'I2S1 Mux 'ADMAIF1'

Which would give us:

|          |---------------->|       |
| ADMAIF1  |                 | I2S1  |
|          |                 |       |

As can be seen, the sink pad as the suffix Mux which is a convention for the sink pads.

Now lets say we want the output of I2S1 connected to the input of ADMAIF1 (a recording path), the command would be:

amixer -c <card number> sset 'ADMAIF1 Mux 'I2S1'

Which would give us:

|          |                 |       |
| ADMAIF1  |                 | I2S1  |
|          |<----------------|       |

So finally, if you want to have playback and recording from I2S1 the commands would be:

amixer -c <card number> sset 'I2S1 Mux 'ADMAIF1'
amixer -c <card number> sset 'ADMAIF1 Mux 'I2S1'

Which would give us:

|          |---------------->|       |
| ADMAIF1  |                 | I2S1  |
|          |<----------------|       |

Some of the modules also have properties that can be modified such as the Master Volume Control (MVC) which has a volume property. The module can be added in the same way as we did in the previous example and the volume can be updated as follows:

amixer -c <card number> cset name="MVC1 Vol" <new volume>

So for example, to set the volume to 50% for module MVC1 of card 1 the command would be:

amixer -c 1 cset name="MVC1 Vol" 50


Finally, as an example, let's say we want the MVC module to control the output volume of I2S1:

|          |       |                 |          |       |
| ADMAIF1  |-------| MVC1 (Vol-50%)  |--------->| I2S1  |
|          |       |                 |          |       |

The commands would be:

amixer -c 1 sset 'I2S1 Mux' 'MVC1'
amixer -c 1 sset 'MVC1 Mux' 'ADMAIF1'
amixer -c 1 cset name="MVC1 Vol" 50

To play audio, aplay or gstreamer could be used.



For direct inquiries, please refer to the contact information available on our Contact page. Alternatively, you may complete and submit the form provided at the same link. We will respond to your request at our earliest opportunity.


Links to RidgeRun Resources and RidgeRun Artificial Intelligence Solutions can be found in the footer below.