No Sound Using I2S to CS4344 Codec

Autonomous Machines Jetson & Embedded Systems Jetson TX2
1

Hi,

I have been trying to interface a CS4344 codec chip to a Jetson TX2 using the I2S1 connection on the J21 Expansion Header. However when trying it out there is no sound playing. I think that the CS4344 codec might not be supported on the Jetson TX2 without adding it myself.

Can I somehow/somewhere check if the CS4344 is supported, and if so, how?

If it is not supported, how do I add it?

I am testing the setup using

aplay -D hw:1,0 /usr/share/sounds/alsa/Front_Center.wav -vv

and when checking the relevant pins with an oscilloscope they seem to produce their expected signals.

Update
I am not sure if “codec” is the right word. The entire chip taking the I2S signals is called PmodI2s, and the ADC on it is a Cirrus Logic CS4344.

Anyways, I have also been experimenting with the audio path by for example

amixer sset -c 1 'I2S1 Mux' 'ADMAIF1'

(though that one seems to be standard), or

amixer sset -c 1 'I2S1 Mux' 'AMX1'
amixer sset -c 1 'AMX1-1 Mux' 'ADMAIF1'

which is pictured in Tegra ASoC Driver-chapter in the L4T documentation, or

amixer sset -c 1 'I2S1 Mux' 'MIXER1-1'
amixer sset -c 1 'MIXER1-1 Mux' 'ADMAIF1'

which was suggested in another thread but with no progress.

2

Probing more with the scope, it seems that the MCLK signal is more sinusoidal than square, which do not seem right. Though I am not certain that the scope is entirely reliable at those rates (it gives a frequency output of ~42 MHz).

3

Hello!

So the correct setting for the audio path is …

amixer sset -c 1 'I2S1 Mux' 'ADMAIF1'

Don’t bother with routing through the ‘MIXER’ (at least to begin with) because this is not necessary.

Typically, there is some configuration needed when adding a codec. However, looking at the datasheet for the CS4344 (which is a simple DAC with an I2S interface and no I2C/SPI interface for configuring it), you should be able to just connect up the I2S signals and it should work. I see the PmodI2s is just a module with the CS4344 on it.

If you see the I2S signals toggling then that is a good sign. By default the I2S interface will use the standard I2S signaling. The MCLK should be 256x Fs by default and so at say 48kHz you should get 12.288MHz.

To check the clock frequencies, while audio playback has started you can …

sudo grep "ape\|ahub\|aud_mclk\|i2s" /sys/kernel/debug/clk/clk_summary

The ‘aud_mclk’ is the clock that drives the external MCLK. The 42MHz does not seem right if this is 48kHz. Dumping the above will provide a bit more info to see what is going on.

Regards,
Jon

4

Thanks for your reply!

Yeah, I assumed that the standard path should be working, but no harm in trying.

Running the command

sudo grep "ape\|ahub\|aud_mclk\|i2s" /sys/kernel/debug/clk/clk_summary

returns

i2s6_sync_input                          0            0           0          0 0  
 i2s5_sync_input                          0            0           0          0 0  
 i2s4_sync_input                          0            0           0          0 0  
 i2s3_sync_input                          0            0           0          0 0  
 i2s2_sync_input                          0            0           0          0 0  
 i2s1_sync_input                          0            0     1536000          0 0  
    i2s1_sync_clk                         0            0     1536000          0 0  
    i2s6_sync_clk                         0            0           0          0 0  
    i2s5_sync_clk                         0            0           0          0 0  
    i2s4_sync_clk                         0            0           0          0 0  
    i2s3_sync_clk                         0            0           0          0 0  
    i2s2_sync_clk                         0            0           0          0 0  
    i2s6                                  0            0    19200000          0 0  
    i2s5                                  0            0    19200000          0 0  
    i2s4                                  0            0    19200000          0 0  
    i2s3                                  0            0    19200000          0 0  
    i2s2                                  0            0    19200000          0 0  
          ape                             0            0   150000000          0 0  
             apb2ape                      0            0   150000000          0 0  
             i2s1                         0            0     1535999          0 0  
             aud_mclk                     0            0    12287998          0 0  
             ahub                         0            0    24575996          0 0

when running a file with a 48000 sample rate. The aud_mclk hits 12.288 MHz as you said, and the i2s1 and ahub hits even powers of two of 48000 as well (or are at least very close). Running a file with a 44100 sample rate provides different rates but with the corresponding ratios, so everything seems fine there. I am not sure what the “ape” or “apb2ape” clocks correspond to.

I did a more thorough probing with the scope, and the 42 MHz I mentioned was due to a poor measurement with a low resistance probe. Fixing that resulted in a way better square wave with a 12.29 MHz rate for aud_mclk. The I2S1_SCLK, I2S1_LRCK and the I2S1_SDATA_OUT also outputted correct rates.

It seems to me that the chip itself might be faulty, and I have ordered a few more, but I wonder if there could be anything else that I could try in the mean time?

5

Don’t worry about the ‘ape’ and ‘apb2ape’ clocks. These are clocks internal to the Audio Processing Engine (APE) and I always dump them all to ensure everything looks good (and it does).

What voltage does the CS4344 expect on the I2S and MCLK pins? I2S is going to be 3.3V and it is not clear to me what this chip is expecting.

Regards,
Jon

6

I see the pmodi2s docs [0] state …

“Any external power applied to the Pmod I2S must be within 3V and 5.25V; however, it is recommended that Pmod is operated at 3.3V.”

So the voltage should be fine if you are powering off the 3.3V rail.

Regards,
Jon

[0] Pmod I2S Reference Manual - Digilent Reference

7

Thanks for looking into it. Yes it is powered off the 3.3 V rail.

I will update when I get the new chips.

8

It turns out the I2S system did work as expected. The I2S-DAC I used had its pins incorrectly marked in the manual I used, referring to an up-to-date schematic solved the issue.

Thanks anyway!

9

Hi NV people

when i use pmodi2s, how could i setting the volume??

10

You could try routing the audio via the Tegra MVC and control it that way …

amixer -c tegrasndt186ref sset 'I2S1 Mux' 'MVC1'
amixer -c tegrasndt186ref sset 'MVC1 Mux' 'ADMAIF1'
amixer -c tegrasndt186ref cset name="MVC1 Vol" 50%

… and adjust the ‘MVC1 Vol’ percentage value to get the desired volume. I am not familiar with the CS4344 chip to know if it can control the volume or not.

Regards,
Jon

11

Hi, sorry for resurrecting this thread but I am having an issue almost identical to this.

I am for the most part very new to I2S though I am trying to get sound to play from the tx2 through the PmodI2S with no success.

The I2S-DAC seems to be wired correctly and I am getting waveforms through it when audio is played yet no sound is coming through when plugged into anything.

I have tried:

amixer sset -c 1 'I2S1 Mux' 'ADMAIF1'

and

amixer -c tegrasndt186ref sset 'I2S1 Mux' 'MVC1'
amixer -c tegrasndt186ref sset 'MVC1 Mux' 'ADMAIF1'
amixer -c tegrasndt186ref cset name="MVC1 Vol" 50%

With neither working.

I have attached a trace which to me looks OK ?

# tracer: nop
#
# entries-in-buffer/entries-written: 30/30   #P:6
#
#                              _-----=> irqs-off
#                             / _----=> need-resched
#                            | / _---=> hardirq/softirq
#                            || / _--=> preempt-depth
#                            ||| /     delay
#           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
#              | |       |   ||||       |         |
           aplay-9993  [005] ...1 353361.543076: snd_soc_dapm_widget_power: widget=Playback 1 val=1
           aplay-9993  [005] ...1 353361.543084: snd_soc_dapm_widget_power: widget=ADMAIF1 Receive val=1
           aplay-9993  [005] ...1 353361.543087: snd_soc_dapm_widget_power: widget=ADMAIF1 RX val=1
           aplay-9993  [005] ...1 353361.543121: snd_soc_dapm_widget_power: widget=I2S1 Mux val=1
           aplay-9993  [005] ...1 353361.543125: snd_soc_dapm_widget_power: widget=I2S1 TX val=1
           aplay-9993  [005] ...1 353361.543127: snd_soc_dapm_widget_power: widget=I2S1 Transmit val=1
           aplay-9993  [005] ...1 353361.543129: snd_soc_dapm_widget_power: widget=I2S1 Transmit-I2S1 CIF Receive val=1
           aplay-9993  [005] ...1 353361.543131: snd_soc_dapm_widget_power: widget=I2S1 CIF Receive val=1
           aplay-9993  [005] ...1 353361.543133: snd_soc_dapm_widget_power: widget=I2S1 CIF RX val=1
           aplay-9993  [005] ...1 353361.543135: snd_soc_dapm_widget_power: widget=I2S1 DAP TX val=1
           aplay-9993  [005] ...1 353361.543137: snd_soc_dapm_widget_power: widget=I2S1 DAP Transmit val=1
           aplay-9993  [005] ...1 353361.543139: snd_soc_dapm_widget_power: widget=I2S1 DAP Transmit-x Playback val=1
           aplay-9993  [005] ...1 353361.543141: snd_soc_dapm_widget_power: widget=x Playback val=1
           aplay-9993  [005] ...1 353361.543143: snd_soc_dapm_widget_power: widget=x OUT val=1
           aplay-9993  [005] ...1 353361.543145: snd_soc_dapm_widget_power: widget=x Headphone val=1
           aplay-9993  [004] ...1 353438.124645: snd_soc_dapm_widget_power: widget=Playback 1 val=0
           aplay-9993  [004] ...1 353438.124658: snd_soc_dapm_widget_power: widget=ADMAIF1 Receive val=0
           aplay-9993  [004] ...1 353438.124663: snd_soc_dapm_widget_power: widget=ADMAIF1 RX val=0
           aplay-9993  [004] ...1 353438.124684: snd_soc_dapm_widget_power: widget=I2S1 Mux val=0
           aplay-9993  [004] ...1 353438.124690: snd_soc_dapm_widget_power: widget=I2S1 TX val=0
           aplay-9993  [004] ...1 353438.124694: snd_soc_dapm_widget_power: widget=I2S1 Transmit val=0
           aplay-9993  [004] ...1 353438.124698: snd_soc_dapm_widget_power: widget=I2S1 Transmit-I2S1 CIF Receive val=0
           aplay-9993  [004] ...1 353438.124702: snd_soc_dapm_widget_power: widget=I2S1 CIF Receive val=0
           aplay-9993  [004] ...1 353438.124705: snd_soc_dapm_widget_power: widget=I2S1 CIF RX val=0
           aplay-9993  [004] ...1 353438.124708: snd_soc_dapm_widget_power: widget=I2S1 DAP TX val=0
           aplay-9993  [004] ...1 353438.124711: snd_soc_dapm_widget_power: widget=I2S1 DAP Transmit val=0
           aplay-9993  [004] ...1 353438.124715: snd_soc_dapm_widget_power: widget=I2S1 DAP Transmit-x Playback val=0
           aplay-9993  [004] ...1 353438.124718: snd_soc_dapm_widget_power: widget=x Playback val=0
           aplay-9993  [004] ...1 353438.124722: snd_soc_dapm_widget_power: widget=x OUT val=0
           aplay-9993  [004] ...1 353438.124725: snd_soc_dapm_widget_power: widget=x Headphone val=0

I have read through a few similar threads and tried following the steps in the l4t documentation.

It is also worth noting I am using an auvidea J120 carrier card for the TX2 and not the dev board.

Any help with this would be greatly appreciated.

Many thanks,
Craig

12

Hi Craig,

Are you saying the you see the I2S signals (bit-clock, frame-sync, and data output) from Tegra active when playing the audio file? If so then that would suggest playback from a Tegra perspective is working fine, but for some reason the audio codec is not outputting the audio. You may wish to check the frequency of the bit-clock and frame-sync look correct. If they do then check the codec is powered correctly as it would imply the problem is on the codec side.

Regards,
Jon