ASoC Driver in Jeston TX1 and TX2
|
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:
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:
NOTE: Add more SFIOs |
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.