Xavier NX I2S5 LRCLK Rate error for 44100 Hz

Robotics & Edge Computing Jetson & Embedded Systems Jetson Xavier NX
1

I am working on Xavier NX Devkit with I2S5 port on 40-pin Connector. I have configured the I2S5 to be master on Xavier, such that LRCLK is generated by Xavier. Everything works ok except that I can’t get LRCLK frequency correct for 44.1 KHz . Frequency is correct for 48KHz, 32KHz, 24KHz, 16KHz and 8KHz.

I use following settings on alsactl for I2S5

  • ‘I2S5 codec master mode’ : cbs-cfs
  • ‘I2S5 BCLK Ratio’ : 0
  • ‘I2S5 Sample Rate’ : 44100

But actual LRCLK is measured to be 45.2 KHz. An error of about 2.4%.

I tried to check the clk_summary, though I don’t understand the clock tree fully
sudo cat /sys/kernel/debug/clk/clk_summary | grep i2s5
i2s5_sync_input 0 0 2822400 2822400 0 0
i2s5_sync_clk 0 0 0 0 0 0
i2s5 0 0 2891293 2822400 0 0

Here to the i2s5 rate is reported to be 2891283, against expected value of 2822400. Which is again off by about 2.5%.

Setting ‘I2S5 Sample Rate’ to 48000, or 32000 etc works ok, and i2s5 rate under clk_summary matches well with expected. Any idea what I am missing?

2

clk_summary.txt (34.1 KB)

The full clk_summary, from /sys/kernel/debug/clk/clk_summary is attached

4

Hello!

Can you tell me what command you are using for playback?

Please note that it is not necessary to explicitly set the ‘I2S5 Sample Rate’. This is only need to override the sample if you are using the hardware sample rate converter and so the sample rate of the PCM stream does not match the sample rate at the I2S interface.

So can you try …

$ amixer -c jetsonxaviernxa sset ‘I2S5 Sample Rate’ 0
$ speaker-test -D hw:jetsonxaviernxa,0 -c 2 -r 44100 -F S32_LE -t sine -f 500

Regards,
Jon

5

Hi Jon,

Thanks for the pointers. Here is some more information

  1. I was doing recording with “arecord” instead of playback. e.g.
    amixer -c jetsonxaviernxa sset “I2S5 Sample Rate” 44100
    arecord -D hw:1,0 -f S16_LE -r 44100 -c2 test_44k.wav

    • With above command running, if I measure the LRCLK on pin-35 of 40-pin header, the LRCLK is approx 45.2 KHz

  2. I have now as well tested with the following command (with “I2S5 Sample Rate” still being 44100)
    speaker-test -D hw:jetsonxaviernxa,0 -c 2 -r 44100 -F S32_LE -t sine -f 500

    • The LRCLK again measures to be 45.2 KHz

  3. If I set the “I2S5 Sample Rate” to 32K or 48K, The frequency changes to desired value correctly, i.e. Pin-35 of 40-pin header measures same as the sample rate which is being set. But sample rate is not accurate for 44.1KHz. So, I wonder if there is any particular limitation w.r.t. 44.1KHz or if some specific configuration needs to be made in software to get this one accurate.

  4. If I set the “I2S5 Sample Rate” to 0 as you suggested, the LRCLK always measures to be 48KHz, no matter what sample rate I set using the “-r RATE” option.

So, looks like the physical value of LRCLK is a bit tricky. I am not sure how exactly it is working. Any idea what I am missing. Or what I could try further?

6

Hello!

I have tried this on my NX and I can see a good 44.1kHz frame clock …

$ sudo grep "plla\|i2s5" /sys/kernel/debug/clk/clk_summary
 i2s5_sync_input                                            0            0     1411200     1411200          0 0  
    i2s5_sync_clk                                           0            0           0           0          0 0  
       plla1_out1                                           1            1   150000000   150000000          0 0  
       plla_out0                                            2            2    45158398    45158400          0 0  
          i2s5                                              1            1     1411199     1411200          0 0

scope_0
scope_0800×503 9.03 KB

From your clock dump, it does not appear that the audio PLL (plla) is being configured as expected. By default the audio PLL is not being updated as it should.

In my case ‘I2S5 Sample Rate’ default to 0 and I never change this …

$ amixer -c 1 sget "I2S5 Sample Rate"
Simple mixer control 'I2S5 Sample Rate',0
  Capabilities: volume volume-joined
  Playback channels: Mono
  Capture channels: Mono
  Limits: 0 - 192000
  Mono: 0 [0%]

If I set to 0 or 44100, it does not seem to make any impact.

Have you made any changes to the kernel drivers or device-tree?

The clocks for the audio driver are set here.

Did you happen to set the following by chance which is overriding the sample-rate passed by arecord?

$ amixer -c 1 sget "codec-x rate"

By the way, I am using L4T r32.5 and after configuring the pinmux, the only command I run is …

$ arecord -D hw:1,0 -f S16_LE -r 44100 -c 2 -d 10 cap.wav

You should not need to configure any mixer controls.

Regards
Jon

7

Hi Jon,
Thanks for your prompt and apt response. The “codec-x rate” appeared to be the culprit. I have now set the “codec-x rate” to “None” and sample rates are accurate. It matches well with whatever I set via “arecord” or “aplay”. I will do more testing and provide you more updates on this.
Thanks Again,
KS

8

Hi KS,

Thanks for confirming. Glad to hear it is working.

Jon

10

Hi Jon,

I have now runn in to another clocking issue, which I hope you can help with again.

(1) What works fine:
When I try to record a 32K 32-bit stereo audio,
word clock is 32 KHz as expected.
bit clock is 2MHz as expected.

(2) What does not work fine:
When I try to record a 32K 16-bit stereo audio,
word clock is 32 KHz as expected.
bit clock is still 2MHz, though we would expect it to be 1 MHz.
Since bit clock is incorrect the audio codec has problem sending the Right channel data correctly. As a consequence the right channel data in the recording gets messed up - its all noise. Left channel data gets recorded correctly.

I have attached the clock summary, and amixer contents dump while making 16-bit recording.

32khz_16_bits_amixer_contents.txt (293.7 KB)
32khz_16_bits_clk_summary.txt (34.1 KB)

Is there anything which looks obviously wrong in our alsa settings?

Thanks and Regards,
KS

11

Hi sinkunal,

Please help to open a new topic for your new issue. Thanks

12

Hi,

I created a new issues here

Best Regards,
KS