Noise while capturing audio over I2S on Xavier Nx

sinkunal · April 16, 2021, 4:34pm

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.

sharadg · April 19, 2021, 10:46am

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

sinkunal · April 20, 2021, 10:06am

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

sinkunal · April 20, 2021, 11:36am

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

sharadg · April 22, 2021, 9:10am

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

sinkunal · April 22, 2021, 11:21am

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:

sharadg · April 23, 2021, 4:55am

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

jonathanh · April 27, 2021, 8:25am

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.

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

jonathanh · April 27, 2021, 10:31am

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

sinkunal · April 27, 2021, 4:39pm

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

sinkunal · April 27, 2021, 4:44pm

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

jonathanh · April 27, 2021, 5:10pm

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

jonathanh · April 27, 2021, 5:12pm

Hello!

It was measured on pins 12 (bit clock) and 35 (frame clock).
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

sinkunal · April 29, 2021, 2:28pm

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

jonathanh · May 10, 2021, 11:17am

Hello!

Sorry for the delay. I see that you are using a picoscope. What exact picoscope are you using? I took the measurements on an Agilent oscilloscope and so possibly the scopes themselves are a difference.

With regard to the gitlab references, unfortunately, gitlab require an account to simply view the files and so I am unable to view or clone the repository.

Regards,
Jon

sinkunal · May 13, 2021, 7:43am

Hi Jon,

(1) I used the “picoscope-3206” to capture signals. I agree with you that using a different scope can lead to different results.

(i) However, note that even when we don’t use a scope, we witness problem in driving the signals at high frequency. So, I have a feeling that problem could be related to some thing other than the scope. As I had previously mentioned we have seen following problem on the SPI1 port of NX board:
Xavier NX is connected to ReSpeaker board through 40-pin header. Respeaker board has an SPI LED driver IC “APA102” and this driver is connected to the "SPI1 of NX " via the 40-pin header (Pins 19, 21, 23). i.e.

     "Xavier NX : SPI1 on 40-Pin header" -> "APA102 on Respeaker board"

When we run a simple LED blinking script on NX board (with SPI clock set to 8MHz) , the LEDs don’t work. However, lowering the SPI clock rate to about 100KHz makes the LEDs to work. This can be explained only if we have a problem in driving the signals at high frequencies. On the other hand, the LEDs works very fine on R.Pi board at 8MHz using the same script.

(ii) While picoscope can be a suspect, it does not explain the behavior of SPI interface as I described in step-(i) above. Additionally, using the same scope I am able to measure high frequency signals on R.Pi board without any issues. The SPI and I2S signals measured on R.PI board look perfect.

(iii) Recently I came across an App note named “Jetson Nano Developer Kit 40-Pin Expansion Header GPIO Usage Considerations”. This app note suggests that the “Voltage level translator IC TXB0108” can have issues in driving the signals. So, I am suspecting the behavior which we are seeing may be due to “TXB0108”. What is your opinion on this?

(2) About the gitlab reference, you should not require any login credentials to view or clone the source code. I have verified it again today and I am able to access the repository without any gitlab login credential.

   You can view the source here:
   https://gitlab.com/aivero/legacy/public/seeed-linux-dtoverlays/-/tree/add_jetson_nx_support

   You can clone the repo using
   git clone https://gitlab.com/aivero/legacy/public/seeed-linux-dtoverlays.git

(3) I appreciate the time you have taken out to help us on this issue. I am hoping that we can arrive at a conclusion which can best explain the behavior which I am seeing on the NX Developer kit. It is all the more puzzling as NX board at your setup works perfectly good. I can think of two possible reasons for this:
(i) We somehow have a wrong PinMux configuration applied to the I2S and SPI pins in our software - e.g. a wrong pull up/down value?
(ii) Or the NX board which I am using is possibly a bit different than the NX board being used by you - e.g. a different model or a diferent version? The board which I am using is named “Jetson Xavier NX Developer Kit” and it is marked “P3518”. Have you used the same platform? If not, can you please share the details of your platform - I can then compare the two hardware schematics to explore any possible differences. However, if you have used the same hardware, then may be it could be a PinMux Config issue in our software?

Best Regards,
KS

jonathanh · May 14, 2021, 4:03pm

Hello!

I did see that some picoscopes have a limited bandwidth but it appears that the one you have should have sufficient bandwidth to capture the signals.

Looking at the source for seeed mic, I can see that it is the I2S master and so it is driving the I2S bit clock and frame sync. So it does not appear to be a problem with Tegra driving the I2S signals. It could be possible that the seeed mic is not able to drive the bi-directional buffer, TXB0108, at higher frequencies. However, this does not explain why you do not see clean signals without the seeed mic and just Tegra driving the I2S bus which is odd. However, I guess the probes themselves could be adding some load the I2S signals in this case.

The boards I have are also label P3518, but this is simply the model number. There should be a revision on the board as well, for example mine are labelled 180-13509-DAAF-A01, where A01 is the revision. Note that there will also be a revision number on the module itself. That said I am not aware of any significant board revisions.

I can see if anyone has any more thoughts on things that can be tried.

Regards,
Jon

jonathanh · May 17, 2021, 9:43am

Hello!

One other interesting data point is that this HAT is supported for Jetson Nano and this has the same bi-directional buffer as Jetson Xavier NX. I will see if anyone has tried this on Xavier NX.

Jon

sinkunal · May 19, 2021, 1:27pm

Hi Jon,

HAT shows same problems on Jetson Nano as it shows on Xavier NX. Since we ran in to issues on Xavier NX, we tested the HAT board with Jetson Nano, as HAT was supported on Jetson Nano. But we faced identical issues.

e.g the SPI LEds won’t work until spi clock is lowered to 100KHz. We contacted seeed about this issue to know how they tested it. Their comment was that they have not have tested the LED feature. This was discussed on seeed forum at this link.

Best Regards,
KS

jonathanh · May 19, 2021, 1:34pm

Hi KS,

Thanks for letting us know. We are checking on our side.

Jon