I have a custom carrier board running the jetson orin agx 32Gb module (from the devkit). It was a whole saga configuring the jetson correctly for our custom board but now it works well!. We are using Jetpack 5.0.2 since it is the only version working with our camera. Out of the modifications, we added access to 4 i2s ports following the schematics from devkit (precisely i2s1, i2s2, i2s4 and i2s6).
To be more more precise, we use each i2s port into a tdm configuration (16 daisy-chained microphones) for each i2s. I2s1 is the master clock generated from the jetson, so we configured it into cbs-cfs. All the other i2s ports are slaves (cbm-cfm) using a clock buffer to synchronize all 4 i2s channels.
We modified the device tree files to be able to have access to those ports : tegra234-p3737-audio.zip (1.9 KB)
Also, I’m joining the device tree files for the fixed-regulators since there has been some modifications there (but i dont know if they did something). tegra234-p3737-fixed-regulator.zip (1.4 KB)
We also have our alsa configuration file, plus our custom alsa sound card : .asoundrc.zip (1.1 KB) config_audio.zip (567 Bytes)
Everything seems to work fine! We are able to record with 64 channels (using both arecord and alsa c++ api; arecord -D 4p16 -r 32000 -f S32_LE -c 64 -d 3 test.wav) and everything seems fine, except sometimes we lose some channels, without even changing the physical configuration or even touching something. In our opinion this must be something due to the configuration or initialization of alsa i2s, but we can’t really pinpoint the source of the problem. That’s where we need some help.
I tested on the oscilloscope to validate i saw the clock (not noisy) and the frame select trigger. Everything worked even for the bad channels. Yellow is i2s1 clock signal and blue is i2s2 clock signal (see reply for signals).
When i mean “losing some channels”, i mean we can still see the data sometimes but the noise becomes way too strong, and other times its just complete garbage). Here is an example of something i can obtain and the channels not working (yellow channels are working → i2s1, green and purple are not → i2s2 and i2s6) :
If no solutions are possible, is there a way to reset the i2s ports using alsa api? I found snd_pcm_reset() function yet it doesnt seem to be working, even if it returns 0.
The only thing that seems to be working right now is restarting the jetson, however it does not always fix it.
From the details you mentioned, it seems like the issue can happen randomly for I2S configured in consumer (slave) mode. The producer (master) I2S is always working I believe.
I would not doubt the SW configuration to begin with because the capture works. However I was expecting if you restart the arecord session again, when issue happens, then it should start working till you see the issue again. The I2S resets are expected to happen for a new arecord session. Can you please confirm if the issue persists even if you restart the arecord?
Are you saying the restart of Jetson also doesn’t help in some cases?
Have you checked with resetting or power cycling external clock buffers on your audio card?
Firstly i can confirm the issue persists after restarting arecord multiple times.
Furthermore, restarting the jetson was helping sometimes before however it is not working now. Like the tests i just did it did not help to remove the noise on i2s6.
I<d like to also mention that finally the issue also happens to i2s1, sorry about the misinformation.
The i2s1 master clock should be running at 65.5 MHz (64 channels * 32 bit * 32 000 Hz), however it is running at a quarter of that rate (see log, at i2s1; 16 383 985 Hz).
No. Please note that you are capturing 16 channels from each i2s and i2s1 clock seems to be as expected for it.
I am suspecting that the issue might be happening because of path delay of clock signals from the clock buffer to Tegra/Mic parts. I am no expert in this area, so I may have to consult the right people here. So may require some time for it.
Meanwhile, is it possible for you to scope master i2s1 clock coming at the clock buffer and all the output clocks of the clock buffer. If this can be put in one snapshot it will help me to discuss internally and analyse the timing diagrams. May be scope may not support these many simultaneous channels, but if it is possible it would be great.
Please share the datasheet of clock buffer and MIC hardware you are using.
Also please check if the intermittency of the issue comes down with the lower sample rates. You can probably try with 8 and 16kHz sample rate captures.
By dropping the frequency i was not able to reproduce the error (in other terms it worked properly), but that is after some short tests, I will test it out more tomorrow.
The phase shift between input and output of clock buffer may cause the issue with i2s1. For lower sample rates may be it is within the tolerance limits and that is why it works.
Is there some issue here? Shouldn’t it be close to what the data sheet says?
But I am curious about the i2s2, i2s4 and i2s6. All of these use outputs of clock buffer for connection to MIC and Tegra. Do you see any phase difference between outputs of clock buffers itself?
Another thing you may have to consider is the MIC array board. What is the board you are using for 16 channel capture? Reference would help. Does standalone capture from MIC array board works reliably with associated Tegra I2S in master/slave. This is to basically rule out any potential external HW issue.
Yea , this is our current working theory. We think that by changing the polarity of the edge control, we might be able to make it work for the slaves i2s.
The fact that this is 5 times bigger than the data sheet delay worries me. I dont think it should be doing that.
About the i2s2, 4 and 6, here are the clock outputs measured twice :
As per the antenna mic hubs, we tested each one of them as masters using our i2s port, and it seemed to work fine, here is the electrical design : MicAntennaHub_SCH REV 1.00.PDF (437.1 KB)
I’m Loïc’s colleague. I also think the problem is related to timing issues, but there is some information I haven’t been able to find yet. Do you know the setup time, hold time and input capacitance of the I2S ports on the jetson? Knowing these informations would be helpful, since the timings requirements seem so tight.
Also, would it be possible to configure all the I2S ports as masters and be sure that they all stay synchronised? Right now, the port that is configured as master is working, so maybe it would be easier to configure all the ports as master and to remove the clock buffer completely? Our concern with that strategy is that we might not be able to keep the different ports synchronised. I guess the clocks should not drift apart, since they are generated from the same source clock, but we don’t know about FSYNC. Is there a way to guarantee that they are synchronised?
I don’t have this info, I will check this with and update once I have the info.
Synchronization cannot be guaranteed. The reason is the clock dividers are different for each I2S. Even though the clock rate requirement is same and the source is same for each I2S, there can be a phase delay between each of them.
I think the issue was seen with I2S1 as well as per the earlier update. Can you cross check this point and confirm?
I am taking feedback from HW experts here and will provide an update. Request for some time for this.
