Jetson TX2 ASoC Driver for Maxim Integrated MAX98357A PCM Class D Amplifier

NVIDIA®JETSON TX2™
Introduction
Getting Started
Compiling Jetson TX2 source code
NVIDIA TX2 NVP Model
GStreamer
Compile gstreamer on Jetson TX1 and TX2 Example pipelines Capture and Display Pipelines H264 H265 VP8 nvgstcapture-1.0 Example pipelines for Jetpack 4.2+ Capture and Display Encoding Decoding Streaming
Performance
Jetson TX2 video latency
V4L2 driver support
V4L2 driver for camera sensor or capture chip V4L2 drivers available for Jetson SoCs Supported camera sensors GMSL MAX96705/MAX9286 Sony IMX219 OmniVision OV5647 Omnivision OS08A10 ON Semiconductor AR0231 ON Semiconductor AR1335 Toshiba TC358743 Toshiba TC358840
HowTo's
How to enable A/B redundancy in TX2 Setting up OpenPose on TX2
Contact Us

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

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

¹ Not sure about the exact pad assignation

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.

RidgeRun Resources

Quick Start Client Engagement Process RidgeRun Blog Homepage Technical and Sales Support RidgeRun Online Store RidgeRun Videos Contact Us

Contact Us Visit our Main Website for the RidgeRun Products and Online Store. RidgeRun Engineering informations are available in RidgeRun Professional Services, RidgeRun Subscription Model and Client Engagement Process wiki pages. Please email to support@ridgerun.com for technical questions and contactus@ridgerun.com for other queries. Contact details for sponsoring the RidgeRun GStreamer projects are available in Sponsor Projects page.