I2S4 audio strange bit clock frequency on Nano being used by system

I have setup the Jetson Nano using I2S4 with an external XMOS mic array and an amplifier for audio out. I used the JETSON-IO tool to enable I2S4 on the 40-pin header.

The IO connections are LRCLK, DATA OUT, DATA IN, BCLK.
The XMOS only supports 48KHz, and is stereo. Amp is configured via I2C - also for 48KHz.
I set up the amixer settings.

All works fine with arecord and aplay with the rate at 48kHZ. can play music or sound files off the web at 48KHz. Using scope I see the bitclock at 3.072MHz.

BUT, for the system and/or using browsers (Chromium e.g.), Nano changes the bitclock to 3.01MHz… which now equates to 47kHz. Which is enough variance for recording sound from XMOS to contain loud white noise drowning out the voice input. If I try to force 48kHz using amixer, then no white noise but sound coming from the system/web (via webRTC e.g.) has a higher pitch and the input from XMOS (albeit no white noise) sent via webRTC has a lower pitch.

It is unclear to me why Nano would vary the frequency like that.

Has anyone else seen this?

I was thinking about trying to set the Nano I2S4 into slave mode and have XMOS drive the bit clock to see if that might override this affect and force the system to work with 48kHz.
I have never modified a Device Tree Overlay file, but seems like it should not be difficult given the instructions from "Configuring the 40-pin header’ documentation.

I am hoping someone may have some insight to what the cause of this might be…?
I am hardware guy, so kind of new to the software side of embedded systems so maybe something simple I am missing.


For the two scenarios that you have described above, one when using aplay/arecord and one using the brower, can you open a terminal and execute the following command while audio is active and let me know what you see …

$ sudo grep i2s3 /sys/kernel/debug/clk/clk_summary

I tried the same and when using the browser and the above shows me that the audio sample rate is defaulting to 44.1kHz in this case. However, this still does not align with the frequency you are seeing which is very odd indeed.

Pulseaudio is the audio server used by the desktop for all system settings and so if you want to force pulseaudio to use 48000 Hz as the default sampling-rate you can force it by …

$ sudo sed 's/; default-sample-rate = 441000/default-sample-rate = 48000/g' -i /etc/pulse/daemon.conf
$ pulseaudio -k


HI jonathan,

I presume you meant i2s4…(?)
so when dumping the clk_summary with aplay using a 48kHz sampled file:

jeff@jeff-jetson:~$ sudo grep i2s4 /sys/kernel/debug/clk/clk_summary
** i2s4_sync 0 0 24576000 24576000 0 0 **
** i2s4 0 0 49151980 11289600 0 0**

But when playing sound from browser:

jeff@jeff-jetson:~$ sudo grep i2s4 /sys/kernel/debug/clk/clk_summary
** i2s4_sync 0 0 24576000 24576000 0 0 **
** i2s4 0 0 45158334 11289600 0 0**

I can say that the aud_mclk when using aplay on 48kHz sample shows on scope as 12.28MHz.
And browser (or system sounds) changes to 11.29MHz.

I changed the conf file for pulseaudio to set the default to 48000 and did ‘pulseaudio -k’ at the command line. Saw no change so did ‘pulseaudio --dump-conf’ and still see default as 44100. Seems the -k did not reload the conf. I can do some digging to figure that out, but wanted to get the clock summary info to you.




I got the conf file for pulseaudio changed correctly and reloaded. So with the system sample rate defaulting to 48KHz, the bit clock seems fixed at 3.072MHz even for sounds from the system/browsers.

I think this will fix my webrtc app. Need to do some more checking but think this is resolved for now.



Please note that the naming in the clock tree starts at 0 and so I2S4, will be I2S3 in the clock summary. So we actually want to look at I2S3 and not I2S4 when checking the clock summary.