I have a Jetson Orin NX 16GB on a dev kit board, and am using an AES audio receiver (TI DIR9001PWR) connected to the 40pin header on the dev kit. This chip operates as an I2S master, and generates the I2S LRCLK and SCLK, and sends I2S SDATA to the Jetson.
I have verified that the DIR9001 is sending I2S data to the Jetson. Here is what it looks like probed at the Jetson Dev Kit’s pins:
Hi
I am reviewing the logs and settings. Meanwhile, could you please provide the pinconf info/dap2?
Is the capture issue present only with CODEC master mode or in slave mode as well?
Is the capture issue present only with CODEC master mode or in slave mode as well?
It is only possible to operate the DIR9001 in master mode (i.e., the DIR9001 generates the LRCLK, SCLK, and data signals), so this issue is with that mode.
Hi Robert,
Could you please set the mixer control as mentioned below? This sets Tegra I2S in slave mode, while the earlier command sets it in master mode.
amixer -c APE cset name==“I2S2 codec master mode” “cbm-cfm”
Also, could you please dump the list of functions that are currently enabled?
sudo /opt/nvidia/jetson-io/config-by-function.py -l enabled | grep i2s2
I tried then setting the mixer master mode back to cbs-cfs, and the error goes away, and the output .wav file is all zeroes (same result as in my original post).
Also, could you please dump the list of functions that are currently enabled?
It seems that the Tegra I2S controller (slave) has failed to receive the LRCLK and SCLK from the DIR9001 (master). To confirm this, could you please attach the kernel log with I2S2 in codec master mode as suggested? Also, please re-confirm with probes.
amixer -c APE cset name==“I2S2 codec master mode” “cbm-cfm”
I won’t be able to do the hardware probes until next week, but will confirm at that point that I’m seeing the I2S data at the Jetson’s 40-pin header.
In the meantime, here are the kernel logs after setting master mode to “cbm-cfm” and attempting to record with arecord (receiving the same “input/output error” message). kernel_log.txt (66.8 KB)
Hi Robert,
Thanks. It seems kernel logs capture only the initial 20 seconds and do not capture the full logs…
In case I2S fails to receive the clock from CODEC, you will see “Failed at I2S2_RX sw reset” prints in logs
The audio configuration to use as follows for Tegra I2S in slave mode:-
amixer -c APE cset name=“ADMAIF1 Mux” I2S2
amixer -c APE cset name==“I2S2 codec master mode” “cbm-cfm”
Hi Ramesh -
That kernel log I uploaded represented the entirety of the kernel log - I had just booted the board before running the test, so there were only 20s of history in the log.
Just to double-check, I’ve performed it again, with this output (note a couple of messages about ADMAIF in the kernel log at the end):
I did also verify that the DIR9001 chip is continuing to provide SCLK, SDIN, and FS to the Jetson’s 40-pin header (probed these signals at pins 12, 38, 35 respectively):
Hi Robert,
Thanks for providing the logs. There is no issue with the ADMAIF prints. Could you please share the hw_params during capture along with the clock summary? cat /proc/asound/card1/<pcm_device>/sub0/hw_params cat /sys/kernel/debug/clk/clk_summary
Have you tried capturing with 16-bit? "The DIR9001 supports MSB-first PCM data output in 24-bit I2S, 24-bit left justified, 24-bit right justified, or 16-bit right justified form. "
Have you tried capturing with 16-bit? "The DIR9001 supports MSB-first PCM data output in 24-bit I2S, 24-bit left justified, 24-bit right justified, or 16-bit right justified form. "
My hardware configuration is for 24-bit I2S format, and you can see in my hardware probing of the I2S stream that there are actually 32 falling edges on the data clock for every LR_CLK transition:
After looking around a bit more at the /proc/asound/card1/ tree, I realized I may have been looking at the wrong device. Based on the table “Port to Device ID Map” I found here, I had assumed pcm3c or pcm7c would be the correct device. However, after examining the /proc/asound/card1/<pcm_device>/sub0/info for a few of the PCM devices, I realized these correspond to the ADMA interface.
Examining pcm0c, this looks like the one I actually want, since it corresponds to ADMAIF1:
Good news! I started playing around with all of the amixer controls, and I now have capture working. I had to set the FSYNC width correctly, but now I get correct stereo data from the DIR9001. The working config for me is: