TDM4 audio capture on AGX vs. Orin Nano

[yasmin.kamali]

I am using the following .dts and amixer setup on both Jetson Orin Nano and Jetson AGX, I am able to capture 4 audio channels on Orin, but the audio captured on AGX is 4x sampling rate(in time domain it’s 4x slower). I am using Jetson as an I2S slave in both case(using external BCLK and SYNC clock that are valid and measured on the probe: BCLK = 48000432, and FSYNC = 48KHz). I know for sure there is no HW issues as the audio is successfully captured on Orin Nano and I am using the same HW for AGX. Here is the .dts and amixer settings. I am using Jetson release 36.4.4 in both cases.

/dts-v1/;
/plugin/;

/ {
overlay-name = “Orin Nano I2S2 TDM4 Slave”;
jetson-header-name = “Jetson 40pin Header”;

/* Fragment 0: Target the I2S2 Controller Hardware */
fragment@0 {
    target-path = "/bus@0/aconnect@2900000/ahub@2900800/i2s@2901100";
    __overlay__ {
        status = "okay";
        
        /* Pin Direction: Orin is Slave (receives clocks) */
        nvidia,codec-bit-clk-master;
        nvidia,codec-frame-clk-master;
        bitclock-slave;
        frame-slave;

        /* TDM hardware parameters */
        nvidia,fsync-width = <0>;   /* 1-bit clock wide pulse */
        nvidia,tdm-mask = <0xf>;    /* Enable 4 slots (0,1,2,3) */
    };
};

/* Fragment 1: Update the ALSA Sound Link */
/* Based on your earlier script, this is dai-link@1 */
fragment@1 {
    target-path = "/sound/nvidia-audio-card,dai-link@1";
    __overlay__ {
        format = "dsp_a";
        num-channels = <4>;
    };
};

};

amixer settiongs:

amixer -c APE cset name=“ADMAIF2 Mux” “I2S2”

amixer -c APE cset name=“I2S2 Capture Audio Channels” 4

amixer -c APE cset name=“ADMAIF2 Capture Audio Channels” 4

amixer -c APE cset name=“I2S2 codec master mode” “cbm-cfm”

amixer -c APE cset name=“I2S2 codec frame mode” “dsp-a”

arecord -D hw:APE,1 -r 48000 -c 4 -f S32_LE tdm4.wav

[carolyuu]

*** Please note that this reply is generated by LLM automatically ***

Based on the provided information, it appears that you are experiencing issues with the audio capture on the Jetson AGX Orin, where the audio is being captured at 4x the sampling rate, resulting in a time-domain signal that is 4x slower. You have confirmed that there are no hardware issues, as the audio is successfully captured on the Jetson Orin Nano using the same hardware.

Comparing the setup on both devices, it seems that the device tree (dts) and amixer settings are identical. However, there might be some differences in the configuration or settings specific to the Jetson AGX Orin that are causing the issue.

Here are a few potential areas to investigate:

1. Codec configuration: Although you have set the codec to master mode using the cbmcfm setting, it’s essential to verify that the codec is indeed operating in master mode on the Jetson AGX Orin. You can check the codec’s configuration using the amixer command or by reviewing the device tree settings.
2. I2S clock configuration: Ensure that the I2S clock configuration is correct on the Jetson AGX Orin. You can check the clock settings using the amixer command or by reviewing the device tree settings. Verify that the BCLK and FSYNC clocks are set to the correct frequencies (48000 Hz and 48 kHz, respectively).
3. TDM configuration: Since you are using TDM (Time-Division Multiplexing) mode, ensure that the TDM configuration is correct on the Jetson AGX Orin. You can check the TDM settings using the amixer command or by reviewing the device tree settings.
4. Device tree settings: Although you mentioned that the device tree settings are identical, it’s essential to double-check that there are no differences in the settings specific to the Jetson AGX Orin. You can compare the device tree files on both devices to ensure that they are identical.
5. Firmware version: Verify that the firmware version on the Jetson AGX Orin is the same as on the Jetson Orin Nano. If there are any differences, it might be worth updating the firmware on the Jetson AGX Orin to match the version on the Jetson Orin Nano.

To troubleshoot the issue, you can try the following:

1. Check the audio capture using a different tool: Instead of using arecord, try using a different tool, such as aplay or ffmpeg, to capture and play back the audio. This can help determine if the issue is specific to arecord or if it’s a more general problem.
2. Verify the audio signal: Use a tool like aplay or ffmpeg to play back the captured audio signal and verify that it’s correct. You can also use a tool like sox to analyze the audio signal and check for any issues.
3. Check the system logs: Review the system logs on the Jetson AGX Orin to see if there are any error messages or warnings related to the audio capture or I2S configuration.

By investigating these potential areas and trying the suggested troubleshooting steps, you should be able to identify and resolve the issue with the audio capture on the Jetson AGX Orin.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

[yasmin.kamali]

I’m sorry, but I don’t find the response very useful, as I said all of these settings work on Orin nano. Is there anything different in AGX (mixer settings or codec/ sound card etc.) that need to be done to capture the correct audio? I have used audacity to capture audio and it’s the same behavior, I don’t believe it’s not arecord issue.

[mkumard]

Hi Yasmin

The previous comment is auto-generated one from AI tool. As you are using same build for both platforms, there should not be any difference in mixer controls. I see one issue for 48KHz, 32bit and 4 channel the BCLK requirement is 48000x32x4 = 6144000 , what I could see from your data is BCLK=480000432. Could you cross check on this.

As I2S is operating as slave the capture of data rate depends on BCLK rate from external codec. Could you also attach the captured wav file in both case.

[yasmin.kamali]

Where do you see BCLK=480000432? I measured and confirmed on the scope BCLK is 6.144MHz.

[yasmin.kamali]

@mkumard

BCLK=480000432

sorry this is a typo

[yasmin.kamali]

Can you tell me what I need to change on the software driver to let the SoC know how many bits per frame the SoC needs to receive? The hardware is sending 32 bits of 4 channel audio at a rate of 48KHz to DIN of the 40 pins header.

In slave mode, the AGX hardware receives the BCLK and FSYNC signals, but the software driver needs to know how many bits make up a single frame to determine the correct sample rate.

• If the driver assumes 32 bits per frame by default, but the hardware receives a 6.144 MHz BCLK, it calculates a sample rate of 6.144 MHz/32 bits=192 kHz

• The correct rate would be 6.144 MHz/128 bits=48 kHz

[mkumard]

In Tegra I2S Slave mode, the I2S sampling would be based on BCLK coming in, so no specific clock programming required from SoC perspective for this. As it is confirmed the external codec is sending right clocks, I would expect valid data in the output dump.

arecord -D hw:APE,1 -r 48000 -c 4 -f S32_LE tdm4.wav

This command ensures SoC records the data at same rate codec is sending to I2S. Could you attach the output dump of both nano and agx. I would like to understand what is the difference. Actually as you are using same build for both boards, the SW driver is same.

[yasmin.kamali]

I had some issues with AGX that I had to build the kernel from scratch and that somehow fixed the issue. Also, maybe part of the issue is amixer settings:

Somehow some of the amixer settings, do not set the value to a correct one when using double quote ““ , so you have to try it with a single quote ‘‘ to make sure value is set to the correct setting:

example : amixer -c APE cset name=“I2S1 codec frame mode” “dsp-a”

This sets the value to 0 instead of 4, by using single quote ‘dsp-a’ the value is set correctly. Not sure if anyone else has reported this, but you should know that is the case.

[mkumard]

Yasmin,

Good to hear it is working. Yes, sometimes copy and pasting the commands has issue with the double quote, best way is to type manually for the commands directly on the target.