Noise while capturing audio over I2S on Xavier Nx

Hi,

We have interfaced a seeedstudio 2-Mic Board to Xavier NX. We use this driver.

The above driver works ok on Raspberry Pi board. On Xavier NX, we get audio data correctly at 32KHz and with 32-bit Samples. But changing the sampling rate to 48KHz introduces terrible noise. Since the identical driver works ok on R.Pi, we assume that data being sent by speaker board over I2S is correct. Any idea if this noise at 48KHz can be cause by some configuration related issue on Xavier NX?

(1) Here is a sample recording at 32KHz 32-bit, which looks fine.

(2) Here is a sample recording at 48Khz 32-bit. We can hear strong tonal noise in this case

We are seting following I2S5 configuration through alsactl
‘I2S5 input bit format’ : None
‘I2S5 codec bit format’ : None
‘I2S5 Sample Rate’: 0
‘I2S5 Channels’: 0
‘I2S5 BCLK Ratio’ : 0
‘I2S5 Capture stereo to mono conv’ : None
‘I2S5 codec frame mode’: i2s
‘I2S5 codec master mode’: cbs-cfs

Any advice will be really appreciated.

Hi sinkunal,

48KHz capture seems to have amplified ambient noise as compared to 32KHz capture. In-fact I observe whistling background noise even in case of 32KHz.
Recordings suggests that the I2S configuration is fine as captured audio (sound) is ok and not garbled. In addition, I2S module doesn’t have any filter which can modify the captured data.

Can you try 48KHz, 32bit capture in a quieter environment and share below information :

  • Clock summary during capture (sudo cat /sys/kernel/debug/clk_summary]
  • Mixer control state during capture (sudo amixer -c 1 contents) (for both 32KHz capture and 48KHz capture usecases)

Please share the RPI HAT product link and attach codec datasheet here?

Thanks,
Sharad

Hi Sharad,

I have made fresh recodings and as well took a dump of clk_summary and amixer contents during recording. All files are attached.

This is the product page of Respeaker 2-MIC Board . Additional information about the product can be found on this wikipageThe codec used on this board is WM8960 and I am attaching the datasheet for it.

Looking forward to hear from you. Please let me know if you want me to run any more tests.

Attachments:
32khz_amixer_contents.txt (293.7 KB)
32khz_clk_summary.txt (34.1 KB)
48khz_amixer_contents.txt (293.7 KB)
48khz_clk_summary.txt (34.1 KB)

32KHz Audio:

48KHz Audio:

Codec Datasheet: WM8960_v4.4.pdf (1.8 MB)

Best Regards,
kunal

Hi Sharad,
One additional input. While probing the I2S bit clock on oscilloscope I found that this signal is not able to transition smoothly.

The signal is generated on the speaker board and NX I2S is slave.

On Pi4 board this signal is smooth. However on Nx the signal does not have sharp edges, and does not have full voltage swing. The screenshot of signal is attached. I believe this must be related to capacitance on this pin. Do you have any suggestions to fix this?


Best Regards,
Kunal Singh

Hi Kunal,

We checked clock summary and mixer control dumps. There are no obvious SW configuration related issues.

As per your first and second comments, NX I2S is configured as Master. But in your last comment, your observations are with NX I2S as slave. I hope there is no typo in this.

To help you further on this, we need some more info. Can you try configuring NX I2S is master mode, probe I2S signals with/without connecting the RPI HAT during capture usecase and share snapshots here.

Thanks,
Sharad

Hi Sharad,
Sorry my bad. Yes, “I2S5 codec master mode” is configured as “cbs-cfs”. So, NX is the master. I was mistaken that clock is generated by Respeaker.

I tested with 2 different setups now

(Setup-1) No Respeaker Board Connection to I2S:
Only Power and I2C connections are made between NX and Respeaker board. Power and I2C connections are needed for the audio card to be recognized by NX. With this configuration, there will be no incoming data in to NX, as Respeaker board I2S port is not connected. However, NX generates the word_clock and bit_clock. The bit_clock is still erratic with this configuration. Note that on this setup nothing has been connected to NX bit clock. Screenshots are attached.

I2S Bit Clock:

I2S Word Clock

(Setup-2): Normal setup with full connections across NX<->Respeaker

I2S bit clock, word clock and I2S data were captured. Screenshots are attached

I2S bit clock:


I2S word clock:

I2S data:

Thanks Kunal, Kindly allow us some time to check and revert on this.

Hello!

I have tested Jetson Xavier NX and I am unable to reproduce the issue you are seeing with the bit clock. On the oscilloscope I see a clean bit clock at 48kHz. I have also tried 96kHz and have not seen any problems either. I have also tested playback with an SGTL5000 codec at 44.1kHz, 48kHz and 96kHz and the bit clock appears to be working OK. Please see the scope screen shots below.

scope_0

I have also captured audio at 48kHz with 32-bit samples with the SGTL5000 codec and was not able to observe and issues.

I don’t have an respeaker mic board, but we can see if we can test this.

Jon

Hello!

Please can you confirm who is the I2S master when you are using the respeaker board with RPi?

Looking at the respeaker board, it appears that it has an on-board 24MHz oscillator and so I would have expected that the respeaker would be the I2S master and drive the bit clock for I2S. Have you tried configuring the respeaker as the I2S bit clock and frame clock master?

Typically, Jetson/Tegra would be the I2S master if we are using the AUD_MCLK source from Jetson to drive the codec MCLK. In this case, because the board as an on-board clock source, then typically the codec would be the I2S master. Otherwise there could be clock drift/skew problems.

Regards
Jon

Hi Jon,

The ReSpeaker Board I2S works as slave. In the case of NX, this is confirmed by the fact that I can still see the I2S word clock and I2S bit clock on 40-pin header, even when Respeaker board I2S signals are not interfaced. Presence of I2S control signals on 40-pin header implies that these are being generated on R.Pi. Just to be doubly sure about R.Pi, I will repeat the same test on R.Pi and get back to you.

I recently came across an app note regarding level translator IC TXB0108. I feel that the problem seen with the I2S bit clock may be related to the same behavior which is described in the App note. We have also seen issues driving SPI clock at a high rates.

Best Regards,
Kunal Singh

Hi Jon,

Thanks for doing these detailed tests. Signals which you have shared indeed look very clean. I have 2 questions

(1) On which pin numbers of the 40-pin header did you measure above 2 signals?
(2) What is the peak to peak voltage level on the I2S bit clock signal in above capture? Is it 4.0 V, or 2.0 V?

Best Regards,
KS

Hello!

This simply means that the Tegra is configured as the master. However, this does not actually confirm that Tegra should be the master. The best way to tell is to review the driver and/or device-tree for RPi. Unfortunately, the driver link listed for gitlab requires a log in. I would be interested to know if this source is available else where.

Regards,
Jon

Hello!

  1. It was measured on pins 12 (bit clock) and 35 (frame clock).
  2. It is 2V per division and so although it is not clear from the image, the signals should be 3.3V peak to peak.

Jon

Hi Jon,

Thanks for your detailed reply.

(1) About the 3.3V peak to peak on I2S Clock, I agree that it looks really good. But we have not been able to see this kind of clean signals on 40-pin Header at higher frequencies. To be more specific we are using “Jetson Xavier NX Developer kit”.

(2) I2S is not the only interface where we have seen trouble in driving high frequency signals. Even on SPI we have identical problem. The Respeaker Board has LED controller connected over the SPI interface - Pins 19, 21 & 23 of 40-pin header. In their LED blinking code the SPI clock rate is set to 8MHz. We could not get LEDs to work on Xavier NX. When we probed the SPI signals, this is how the SPI signals looked at 8MHz

 When we reduced the spi clock rate to 100 KHz, SPI signals were ok as shown below and LEDs worked too.

Based on an Application Note from Nvidia we realized that these problem may be related to the “TXB0108 Level Shifter”. What do you think? Btw, we have seen signal degradation even when no load is connected to the 40-pin header.

(3) The oscilloscope traces which you have shared show very clean signals. Do you know what could make this difference on your setup? Shouldn’t the signals be identical atleast when no load is connected? Or do you use a different pinmux setting which make the signals better on your setup?

(4) I am very sorry that you were not able to access the Respeaker driver code which I shared earlier. It was a mistake from our side as the previous repository was moved to another place and access rights were mistakenly changed. You should be able to clone the repo now from this link. In order to install the software on Xavier-NX, you could use Instructions from This Link

To summarize the relevant steps, you need to run the following commands.

	cd <your-work-directory>
        git clone https://gitlab.com/aivero/public/legacy/seeed-linux-dtoverlays.git
	cd seeed-linux-dtoverlays
        git checkout origin/add_jetson_nx_support

	export CUSTOM_MOD_LIST="jtsn-wm8960"
	make all_xaviernx
	sudo -E make install_xaviernx

	sudo cp overlays/xaviernx/xavier-nx-seeed-2mic-wm8960-with-led.dtbo /boot
	sudo /opt/nvidia/jetson-io/config-by-hardware.py -n "Seeed Voice Card 2MIC"
	sudo reboot

	cd <seeed-linux-dtoverlays-repo>
	alsactl -f extras/wm8960_asound.state-xavier-nx-new restore 1

(5) After you install the software from step-4, you should be able to connect Xavier-NX to Respeaker board. But even if you don’t have Respeaker board, you should at least be able to run their LED blinking code and you can observer the problem with SPI signals just by mesuring the signals on 40-pin header. Following are the instructions to run the LED blinking code as per ReSpeaker-Wiki-Page.
Here are the commands used:

   sudo pip install spidev
   cd ~/
   git clone https://github.com/respeaker/mic_hat.git
   cd mic_hat
   python pixels.py

(6) The ReSpeaker board schematics is attached here for your reference in case you want to have a quick look at it.
ReSpeaker 2-Mics Pi HAT_SCH.pdf (37.4 KB)

I hope that above information might give you some additional pointers to assess why we are facing problems on Xavier NX board. I will wait for your analysis and hopefully we can resolve at least some of the issues we are facing. In case you need any clarification on my email above, please feel free to ask.

Best Regards,
KS