TLV320AIC3104: Audio playback is not working on Custom Board using TLV320AIC3104 audio codec (Works with EVM)

Adding a comment to provide more information for this question. 

Below is our codec schematic, and highlighted in green are showing where we are checking the audio signal. Note that on the EVM, we are able to get clear audio out on both of these audio outputs (line out L + R and headphone L + R). 

Here is the Register Table we have applied to our codec on our custom host board. Note this Register Table was copied from the AIC310X EVM GUI software. 

2025-08-05 - TI 3104 Codec Register Table.xlsx

Adding another comment, regarding Register 108. 

Per our schematic, we are only routing audio to LEFT_LOP and RIGHT_LOP (line out plus). Based on this, we believe we may need to set Register 108. However, the register name implies this setting only takes effect during power down of the codec. 

Note that enabling these in the EVM does not seem to affect the audio output at the line outs on the EVM line out terminal. 

Hi Nazar and Vidit,

There are a few things we can try first:

I would recommend running the software reset register at the beginning of your script, this would be "w 30 01 80". Then, we can know we are starting from the device defaults. After this, running the script from the GUI should work the same as running the script on the EVM. Another issue I am noticing is that your headphone and audio_amp connections seem to be wrong - normally we would put headphone-L on "HPLOUT+" and it would be referenced to HPLCOM, and headphone-R would be on HPROUT+ and referenced to HPRCOM. So, putting the headphone connections on HPLCOM and HPRCOM will require more attention to the registers that configure those outputs. This would be with register 68 (0x44), which is the routing from DAC_L1 to HPRCOM, and register 57 (0x39) which is routing from DAC_R1 to HPLCOM. 

As for the line out registers, yes you do NOT need register 108 that you shared. The main registers to enable line outputs as DAC outs would be register 82 (0x52), sending DAC_L1 to LEFT_LOP/M, and register 92 (0x5c) sending DAC_R1 to RIGHT_LOP/M. 

Let me know if doing the software reset helps, and if you make progress with changing the headphone routing as I suggested. Or if you need more help with my suggestions.

Best,
Mir

Hello Mir Jeffres , 

Thank you for looking into it and for your feedback.

We ran tests based on input. However, the result is the same. We cannot hear audio on line outs while using RAW I2C write.

We did some additional testing and were able to play various audio files over line out using amixer instructions. However, audio output was relatively low, noisy and signal quality was really bad.

Here's a list of artifact from our most current testing uploaded on shared driver folder
drive.google.com/.../1autTsDBfbtlFe8tXkaox2s7S1OVhypuo

1. amixer script for line out (Line_out_audio_amixer.sh)
2. sound output (2025-08-07 - Audio playing with settings applied using Amixer.MOV)
3. signal quality (2025-08-07 - Audio signal with settings applied using Amixer.MOV)

I also attached amixer possible contets (TLV320AIC3104_Codec_amixer_contents.txt) and amixer possible controls (TLV320AIC3104_Codec_amixer_controls.txt) from the application layer. 

Our goal is We’re trying to get clean audio output through the Line-Out channels (LEFT_LOP+ / RIGHT_LOP+), as shown in the screenshot, on our custom board using the TLV320AIC3104 codec. 

Could you kindly review and assist us in identifying glitches or modifications to the amixer controls we are currently using? 

Regards,
Vidit

Hi,

Can you share a scope shot of your I2S clocks? Also, can you send a register dump? My main note to help with low volume on the output is to increase the "Line DAC Playback Volume" to 100, as this is likely the stage BEFORE the PCM playback volume so any decrease from the max there will be a reduction in the gain stage on the output. A register dump will help the most here. I have a feeling that the drivers are setting something different than you expect.

Best,
Mir

Hello Mir Jeffres ,

Thank you for the feedback. Playback volume worked as you suggested.  However, still we here lots of background noise(hiss) sound once we activate the codec settings, even when we are not playing the audio.

Based on request, we dump codec register based on amixer configurations.  Plus, we probed MCLK as well and seems to normal as expected.

However, Line out pins very noisy and distorted while playing standard 440Hz sine wav file. It gives clear sine wave when we test with EVK.

Test results attached to one drive, drive.google.com/.../1autTsDBfbtlFe8tXkaox2s7S1OVhypuo

1. 2025-08-08 - Register dump Line PCM Playback Volume 70.txt
2. 2025-08-08 - Register dump Line PCM Playback Volume 100.txt
3. 2025-08-08 - Noise on audio line custom 440Hz .jpeg
4. 2025-08-08 - Line_out_EVK_440Hz.png

Kindly review and give your feedback on possible misconfiguration at driver level.

Regards,
Vidit

Hi Vidit,

One more thing, how are you connecting to your line out M pins? I see not connected, but then what are your differential inputs to your speaker? How did you connect it to the EVM?

Also, I don't think these register dumps are while signal is playing, so it says the line outs are muted. If you can take the reg dump while it is playing it will be more helpful.

Best,
Mir

Hello Mir Jeffres , 

Here is the inline response to your questions.

Mir Jeffres said:

One more thing, how are you connecting to your line out M pins? I see not connected, but then what are your differential inputs to your speaker? How did you connect it to the EVM?

 
We have a separate Amplifier board using the TPA3255TDDVRQ1 which has its own differential signal generation. So it is only using Line Out P. Note that we have tested this audio amplifier board, and it is operating properly on different audio setups. So, we are more focused on direct output from the codec itself.

Mir Jeffres said:

Also, I don't think these register dumps are while signal is playing, so it says the line outs are muted. If you can take the reg dump while it is playing it will be more helpful.

Attached codec register dump while playing audio, along with before and after data as well.
docs.google.com/.../edit

Below are testing observations on audio signal probing while playing sine wave audio files.

1. As highlighted in the screenshot, we are probing audio signals at the TP81 and TP85 while playing the audio files.


Here is probing output on the line out on the custom board 

Where on the EVK line out P+ or M- lines we have clean sine wave audio.
  



Note: During the preceding test, we played the identical sine wave file on both EVK and the custom board, and we set up the custom board audio code using amixer setting (2025-08-08 - Register dump Line PCM Playback Volume 70.txt). 

Test Conclusion:  

As evidenced by the test results, we have very poor signal output on the audio codec's line and headphone lines, but a clear audio signal on the EVK line output. Based on the many tests, we firmly believe that we need to fine-tune the codec settings to provide a superior audio output.

We seek your input to fine-tune codec settings to achieve proper audio quality. 

Regards, 
Vidit 

Hi Vidit, 

Can you provide your MCLK rate? I think it may be a clocking issue. Can you measure your BCLK and WCLK clocks out as well? What do you intend them to be? Is MCLK=24.576MHz? Another thing to check is are all the supply voltages coming in correctly? It looks like your output may not be at the common mode of 1.35V, since it looks lower than the example. This may be due to the voltages not making it in correctly, the power supply sequencing may be incorrect. Please follow section 12 of the datasheet for power supply recommendations: 

One more power thing to note is that your IOVDD is 1.8V so all digital signals should be at 1.8V. Make sure your I2S signal in is at 1.8V and not 3.3V.

Best,
Mir

Hello Mir Jeffres , 

Thank you for your feedback.

Please find inline response to your question. 

Mir Jeffres said:

Can you provide your MCLK rate?

 
Ans - MCLK rate is 24.576MHz. Here is a snapshot of MCLK measurement using an Oscilloscope. It is as intended. 

Mir Jeffres said:

Can you measure your BCLK and WCLK clocks out as well?

Ans: Here are the Oscilloscope measurements on

BCLK

WCLK

Mir Jeffres said:

Another thing to check is are all the supply voltages coming in correctly?

Ans: Yes, all the supplies are coming properly. Here are the measurement readings from different pins. 

Mir Jeffres said:

One more power thing to note is that your IOVDD is 1.8V so all digital signals should be at 1.8V. Make sure your I2S signal in is at 1.8V and not 3.3V.

Ans: Here is the measurement on

DIN

Let me know If I am missing anything here. 

Regards, 
Vidit

Hi Vidit,

One more question for you and then I will dive deeper into your register dump - how are you configuring the EVM? Running the same register configuration or are you using a GUI? Can you provide the reg dump from the EVM as well?

-Mir

Hello Mir Jeffres , 

Based on your request, here are the register dump of EVM while no audio is playing and while audio is playing,

https://docs.google.com/spreadsheets/d/1KJ9_VOe-mSZ9ZeeRIaz3VnAZPnJa-mOyfYLdT6xH3cU/edit?gid=0#gid=0

Register dump with EVM settings being applied through the GUI.

https://docs.google.com/spreadsheets/d/1KJ9_VOe-mSZ9ZeeRIaz3VnAZPnJa-mOyfYLdT6xH3cU/edit?usp=sharing

Regards, 
Vidit

Hi Vidit,

The new reg dumps look to be the same file.

I was able to compare this EVM dump with a previous register dump you had provided of your device that is controlled by ALSA, and the main things I noted about the differences here have to do with the outputs:

Looking at registers 65, 72, 94, and 95, we see that on the EVM, the headphone outputs are muted, turned off, and set to high impedance when not powered on, and on your board, they were muted but not set to high impedance, and powered up. On the EVM the only output that is powered up is Left_LOP/M and Right_LOP/M. Another thing to note is registers 82 and 92 set the gain reduction on the DAC_L1 and R1, and we see on your board the gain is reduced by ~24dB and the EVM is reduced by 0dB. So, the signal coming through on any outputs on the EVM will be much louder than the outputs on your board. 

You also seem to have some inconsistencies in the clocking, there is a missing register or two in your EVM register dump, but also the PLL looks to be disabled or set to an invalid value on your EVM, as well as being in slave mode on the EVM but master mode on your board. Can we verify what direction your clocks are coming from, and what your PLL settings are, on the EVM?

Let me know if this helps... I would recommend you try to run the register dump from the EVM on your board, and from there see if you are able to replicate the performance. You would need to do it after alsa is done changing your settings, since the drivers also control the I2C registers on the chip.

Best,
Mir

Hello Mir,

It seems to us the EVM register dumps, and even the register dumps from our own board are not working consistently as expected, even based on your feedback. 

Part 1: Register Settings from EVM

Here is a step-by-step example of this inconsistency using Register 82 as an example. 

Step 1: Apply the following settings using the TI EVM GUI for Left DAC and Left Line Out. 

Step 2. Observe the register table. As expected, Register 82 has a value of 0x80 from the settings we applied in Step 1. 

The value of 0x80 also matches the datasheet description for Register 82. So far so good. 

Step 3. Play audio and refresh the Register Table, since you previously mentioned to capture register settings while playing audio. Here is where the inconsistency happens.

If we use the EVM GUI to "Refresh" the Register Table, while playing audio, the value of Register 82 gets updated to 0x00. Which is not expected as per the settings and datasheet. See the screenshot below.

PART 2:  Testing register settings with our custom board. 

Now let's look at our custom board and see how it works. We did the following steps. 

Step 1. Apply our AMIXER commands for configuring to play to line output. 2025-08-07 - Line_out_audio_amixer.sh

Step 2. Manually set custom register values to Registers 65, 72, 82, 92 since you mentioned these are suspect. We copied the values from the EVM captured in Step 2 in Part 1 above. Here are the commands fired.

root@verdin-imx8mp-tf3-controller-15504931:~# i2cset -f -y 0x1 0x18 0x41 0x00
root@verdin-imx8mp-tf3-controller-15504931:~# i2cset -f -y 0x1 0x18 0x48 0x00
root@verdin-imx8mp-tf3-controller-15504931:~# i2cset -f -y 0x1 0x18 0x5C 0x80
root@verdin-imx8mp-tf3-controller-15504931:~# i2cset -f -y 0x1 0x18 0x52 0x80

Step 3. Read the register settings before playing, during playing, and after playing audio. Note they change unexpectedly.

E.g.

Register 82: Before playing = 0x80 (as expected)
Register 82: During playing = B0 (not expected and different value than 0x00 which was what we observed on the EVM)
Register 72: After playing = 0x00 (not expected)

We also probe the audio signal coming out of Line Out L/R and observe the same poor signal. Here is the full register dump from the codec on our custom PCB:

https://docs.google.com/spreadsheets/d/1xf1lmhw-J_cPw5t7mlN2rXDoOcbTMzNz6LI3HOt22Mg/edit?usp=sharing 

Step 4. Try setting all register values copied from working settings on the EVM directly to the codec on our custom board. We observe the same issues.

Issue 1> Register values change unexpectedly before playing, during playing and after playing audio
Issue 2> Noisy signal coming out of Line Out L/R.

Thanks,

Nazar

Hi Nazar,

Sorry about my delay in response. I went through your most recent register dump and have commented where I think the issue is. Sorry, we do not use Google Drive at TI so I have to download as Excel.

 2025-08-21 - Codec Dump from Custom PCB _ MIRNOTES.xlsx

These changes that occur during or after playback are likely from ALSA/the drivers, updating registers such as the routing, volumes, and some flag registers. The main thing I was noticing was near the beginning of the register dump, the device sets itself to 44.1kHz mode during playback and back to 48kHz mode after (like it was before). It also changes from slave to master mode (the clocks are outputting from BCLK and WCLK rather than input, but only during playback). There is also a data offset that occurred during the first playback but not the second, as it was set before playing. If you could read my notes in the excel sheet and let me know what you think, and we can figure out how to output clean signals through the DAC.

Best,
Mir

Hello Mir,

Thank you for the detailed review of the register dump.

Register Expected Values (yellow cells)

We have reviewed your feedback and see there are a total of 9 cells highlighted in yellow - does this color coding mean these register settings are incorrect? Could you provide us with the expected register values?

Registers 7 and 8

We agree with the observations for Register 7 and Register 8 as being problematic. We understand for Register 7, the expected value should be 0x0a. For Register 8, we're not sure what the expected value should be (master or slave)? We are also not sure how to properly set these registers to the correct value before playback, because when we perform the playback, the registers seem to change during playback anyway. 

ALSA / Aplay

We are using the following aplay command to perform playback (aplay -D sysdefault:CARD=tf3aic3104 440Hz_44100Hz_16bit_30sec.wav). Should we be performing playback using a different method to better control the registers during playback?

ALSA / Amixer

Are we applying incorrect settings via amixer? I've attached our amixer settings that are being applied. Note that we have tried to run our amixer settings script, and then followed by updating register values as per feedback from this thread previously, to try to apply the exact register settings required.

Thanks,

Hi,

The register settings changing during playback is to be expected, this is from the Linux drivers for the device. You can control them somewhat with your DTS file and yes, your amixer settings - although amixer settings are mostly for the input/output routing, not the clocks. The yellow highlights were what I thought could be indicative of your problem. All the highlighted cells were things that were changed between before playing and during, just so I could see it better. 

Master or slave mode, or sample rate are all things you will need to specify in your DTS file. Master mode (sometimes called controller mode) means you provide one clock (typically MCLK) and the codec outputs BCLK and WCLK. Slave mode (sometimes called target mode) means you provide all ASI clocks to the codec.

If you could provide your dts file that may help more. And now that you can understand what I mean by the clocking, you can explain how you are sending your clocks to the chip.

Best,
Mir

Hello Mir Jeffres , 

Thank you for the feedback on register settings.


As requested, here is the overall DTS configuration for the TLV320AIC3104 audio codec.

Hi Vidit,

Today is a U.S. holiday. Please be patient as our team follows up with you tomorrow.

Thank you!
Jeff McPherson

Hi Vidit,

Looks like you are in master mode - the "bitclock-master" and "frame-master" are the codec. So, they will provide the output clocks, provided the MCLK is correct and the driver is able to calculate the correct clock dividers. Are you really providing a 24.576MHz MCLK? What are the measured WCLK and BCLK coming out of your codec during a recording/playback?

Best,
Mir

Hi Mir,

Here is the MCLK, it is measured around 24.5 MHz during playback, so as expected:

Here is BCLK, measured around 1.4 MHz during playback (0.1 microsecond per div, 7.1 divs): 

Here is WCLK, measured around 43.4 KHz during playback (5 microsecond per div, around 4.6 divs):

Hi,

Looks like your clocks are outputting like it is 44.1kHz mode - this is fine, if you intend to play 44.1kHz files. Can you verify that you are playing a 44.1kHz file, or if it is 48kHz, you should include "-r 48000" in your aplay command? Maybe the resampling is making the audio different than you expect?

Also, I am about to go out of office for a few days so we may have someone else help here. Can you recap your issue again, and what you have tried to fix it, for clarity?

Best,
Mir

Hello Mir,

Recap of the issue:

1. We are feeding audio to DIN of the AIC3104 codec. All other inputs are unused (and muted per settings we apply).

2. When we listen to the output on any of headphone out or line out, we can hear the audio, but it is noisy. Listen here. 

3. If we analyze the analogue audio signal, we can confirm it is noisy (see this photo taken by probing line out). 

4. We can play the same audio using the EVM and get clean audio out (see this photo taken by probing line out). 

5. Here is our DTS (in this support thread). We've also tried various amixer commands for setting output and playing audio (e.g. here and elsewhere). 

6. If we attempt to the register table from the EVM and write those registers to the codec on our host, it does not improve the audio output. 

Thanks,

Hi,

Your audio example is not clear, are you playing the piano sound or a sine wave? I am still confused as to what the "noise" is - if you can provide the input signal as well as the output signal, on a scope or just the raw files, that would be more help than a video of your scope. As well as if you can provide the output signal from the EVM on the same scope shot that would be helpful as well. From what you have sent, it looks like there is no signal on your board but there is signal on the EVM. Can you show where you are probing on your schematic as well as where you are probing on the EVM schematic? If you did put the same script on both the EVM and your board, and then get noise out on your board but not the EVM, it seems like it is a board issue (might be power, might be clocks not the same, etc). So, if you can sanity check your power supplies on the two chips as well as the clocks side by side, and the I2S signal making it to the chip that might help illuminate your issue. If you can provide me with the registers or the script you are running that can help as well. I would prefer to not have these files over google drive, if you can attach them to your post here that would be best. Insert->Code will let you do in line code on E2E.

Best,
Mir

Hello,

The audio example was playing a piano - that was shared since it is easy to hear on a video what is being played (as opposed to a sine wave which is hard to tell).

Here are requested items:

1. Input signal - as mentioned, we are inputting to DIN on the codec. Going forward, we'll use only the sine 440hz audio. Here is the audio file. It is on Google Drive since this support site doesn't allow uploading files. 

2. Output signal from LEFT_LOP (test point 81) or RIGHT_LOP (test point 85) while playing the 440hz sine. As mentioned previously, we can hear the audio, which is a bit faint, and surrounded by a lot of noise. So the digital input audio signal is coming in, we are hearing the audio playing. That's what's visible while scoping these test points in the image below.

3. Output signal on LEFT OUT + or RIGHT OUT + on the EVM while playing the 440hz sine. The audio is clear, and we get a nice clear sine wave while probing these outputs. 

4. We are not putting the same script on the EVM as with our board. The EVM is run through your AIC 310X GUI utility which runs on Windows. The codec on our host PCB operates on Yocto. 

5. As shared earlier, the power supplies to the codec are correct, do not have noise, and the clocks seem correct as well (unless you can spot an error). The clock outputs were shared on August 18 and September 3, most recently here.  

6. Here is the amixer script:

# ===== Volume and Digital Path Settings =====
amixer -c 0 cset name='PCM Playback Volume' 100,100
amixer -c 0 cset name='Line DAC Playback Volume' 70,70
amixer -c 0 cset name='Line PGA Bypass Volume' 0,0
amixer -c 0 cset name='Line Playback Volume' 5,5

# ===== DAC to Line Path (Enable Only LOP/ROP) =====
amixer -c 0 cset name='Left DAC Mux' 'DAC_L1'
amixer -c 0 cset name='Right DAC Mux' 'DAC_R1'
amixer -c 0 cset name='Left Line Mixer DACL1 Switch' on
amixer -c 0 cset name='Right Line Mixer DACR1 Switch' on
amixer -c 0 cset name='Line Playback Switch' on,on

# ===== Disable All Other Outputs =====

## Headphone Outputs
amixer -c 0 cset name='Left HP Mixer DACL1 Switch' off
amixer -c 0 cset name='Right HP Mixer DACR1 Switch' off
amixer -c 0 cset name='HP Playback Switch' off
amixer -c 0 cset name='HP DAC Playback Volume' 0,0
amixer -c 0 cset name='HP PGA Bypass Volume' 0,0
amixer -c 0 cset name='HP Playback Volume' 0,0

## HPCOM Outputs
amixer -c 0 cset name='Left HPCOM Mixer DACL1 Switch' off
amixer -c 0 cset name='Right HPCOM Mixer DACR1 Switch' off
amixer -c 0 cset name='HPCOM Playback Switch' off
amixer -c 0 cset name='HPCOM DAC Playback Volume' 0,0
amixer -c 0 cset name='HPCOM PGA Bypass Volume' 0,0
amixer -c 0 cset name='HPCOM Playback Volume' 0,0

## Line Bypass Paths (PGAs to Line)
amixer -c 0 cset name='Left Line Mixer PGAL Bypass Switch' off
amixer -c 0 cset name='Left Line Mixer PGAR Bypass Switch' off
amixer -c 0 cset name='Right Line Mixer PGAL Bypass Switch' off
amixer -c 0 cset name='Right Line Mixer PGAR Bypass Switch' off
amixer -c 0 cset name='Left Line Mixer DACR1 Switch' off
amixer -c 0 cset name='Right Line Mixer DACL1 Switch' off

## HP Bypass Paths
amixer -c 0 cset name='Left HP Mixer PGAL Bypass Switch' off
amixer -c 0 cset name='Left HP Mixer PGAR Bypass Switch' off
amixer -c 0 cset name='Right HP Mixer PGAL Bypass Switch' off
amixer -c 0 cset name='Right HP Mixer PGAR Bypass Switch' off

## HPCOM Bypass Paths
amixer -c 0 cset name='Left HPCOM Mixer PGAL Bypass Switch' off
amixer -c 0 cset name='Left HPCOM Mixer PGAR Bypass Switch' off
amixer -c 0 cset name='Right HPCOM Mixer PGAL Bypass Switch' off
amixer -c 0 cset name='Right HPCOM Mixer PGAR Bypass Switch' off

## PGA / MIC Inputs
amixer -c 0 cset name='Left PGA Mixer Mic2L Switch' off
amixer -c 0 cset name='Left PGA Mixer Mic2R Switch' off
amixer -c 0 cset name='Right PGA Mixer Mic2L Switch' off
amixer -c 0 cset name='Right PGA Mixer Mic2R Switch' off
amixer -c 0 cset name='Left PGA Mixer Line1L Switch' off
amixer -c 0 cset name='Left PGA Mixer Line1R Switch' off
amixer -c 0 cset name='Right PGA Mixer Line1L Switch' off
amixer -c 0 cset name='Right PGA Mixer Line1R Switch' off
amixer -c 0 cset name='PGA Capture Switch' off
amixer -c 0 cset name='PGA Capture Volume' 0,0

## Miscellaneous Unused Features
amixer -c 0 cset name='AGC Switch' off,off
amixer -c 0 cset name='De-emphasis Switch' off,off

7. Here are the relevant DTS snippets:

/ {

 /* Carrier Board Supply +V1.8 */

 reg_1p8v: regulator-1p8v {

 compatible = "regulator-fixed";

 regulator-max-microvolt = <1800000>;

 regulator-min-microvolt = <1800000>;

 regulator-name = "+V1.8_SW";

 };



 /* Carrier Board Supply +V3.3 */

 reg_3p3v: regulator-3p3v {

 compatible = "regulator-fixed";

 regulator-max-microvolt = <3300000>;

 regulator-min-microvolt = <3300000>;

 regulator-name = "+V3.3_SW";

 };



 sound_card: sound-card {

 compatible = "simple-audio-card";

 simple-audio-card,bitclock-master = <&dailink_master>;

 simple-audio-card,format = "i2s";

 simple-audio-card,frame-master = <&dailink_master>;

 simple-audio-card,name = "tf3-aic3104";

 simple-audio-card,widgets = "Line", "Line Out",

 "Line", "Line In";

 simple-audio-card,routing = "Line Out", "LLOUT",

 "Line Out", "RLOUT",

 "MIC2L", "Line In",

 "MIC2R", "Line In";



 dailink_master: simple-audio-card,codec {

 sound-dai = <&tlv320aic3104_18>;

 clocks = <&audiomix_clk IMX8MP_CLK_AUDIOMIX_SAI1_MCLK1>;

 };



 simple-audio-card,cpu {

 sound-dai = <&sai1>;

 };

 };



};



/* Verdin I2C_2_DSI */

&i2c2 {

 status = "okay";



 /* Audio Codec */

 tlv320aic3104_18: audio-codec@18 {

 compatible = "ti,tlv320aic3104";

 reg = <0x18>;

 #sound-dai-cells = <0>;

 clocks = <&audiomix_clk IMX8MP_CLK_AUDIOMIX_SAI1_MCLK1>;

 clock-names = "mclk";

 DCVDD-supply = <&reg_1p8v>;

 DBVDD-supply = <&reg_1p8v>;

 AVDD-supply = <&reg_1p8v>;

 CPVDD-supply = <&reg_1p8v>;

 MICVDD-supply = <&reg_1p8v>;

 };

};




/* VERDIN I2S_1 */

&sai1 {

 #sound-dai-cells = <0>;

 assigned-clocks = <&clk IMX8MP_CLK_SAI1>;

 assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL1_OUT>;

 assigned-clock-rates = <24576000>;

 clocks = <&audiomix_clk IMX8MP_CLK_AUDIOMIX_SAI1_IPG>, <&clk IMX8MP_CLK_DUMMY>,

 <&audiomix_clk IMX8MP_CLK_AUDIOMIX_SAI1_MCLK1>, <&clk IMX8MP_CLK_DUMMY>,

 <&clk IMX8MP_CLK_DUMMY>;

 clock-names = "bus", "mclk0", "mclk1", "mclk2", "mclk3";

 fsl,sai-mclk-direction-output;

 pinctrl-names = "default";

 pinctrl-0 = <&pinctrl_sai1>;

};

Thanks

Hi,

Have we verified all potential issues with your register dump? Could you re-measure the changes during playback of the register dump? You can also check the register dump of the EVM in the GUI, you can verify the changes in the GUI that you are making line up with the registers that are being set in the Linux system. Any settings set through the GUI are actually sending I2C commands to the chip, and the GUI should save it in the "Command Line Interface" page as shown here:

Then, you can export the registers set in the device on the "Register Table" tab as shown here:

You can check the register table with your register dump of the custom board, and I can as well if you send it over.

Best,
Mir

First approach with our custom board:

Step 1. Apply our AMIXER script for configuring the codec to play to line output. 

Step 2. Manually update Registers 65, 72, 82, 92. We copied the values from the EVM captured using the EVM GUI command buffer. Here are the commands fired.

root@verdin-imx8mp-tf3-controller-15504931:~# i2cset -f -y 0x1 0x18 0x41 0x00
root@verdin-imx8mp-tf3-controller-15504931:~# i2cset -f -y 0x1 0x18 0x48 0x00
root@verdin-imx8mp-tf3-controller-15504931:~# i2cset -f -y 0x1 0x18 0x5C 0x80
root@verdin-imx8mp-tf3-controller-15504931:~# i2cset -f -y 0x1 0x18 0x52 0x80

Step 3. Read the register settings before playing, during playing, and after playing audio.

2025-08-21 - Codec Dump from Custom PCB.xlsx

Second approach with our custom board:

Step 1. Try setting all register values using values copied from the EVM register table directly to the codec on our custom board. We observe the same issues.

Thanks,

Hi,

I wonder if this is a hardware issue. I notice that you did not separate analog and digital grounds on DRVDD and AVDD, so any analog ground connection on the output would also be incorrect. Can you separate analog and digital grounds and continue to test? Noise in the output may be a power supply/separation problem, or a connection problem. 

Best,
Mir

Hi,

Do you mean DVSS, DRVSS (which are connected to GND) and AVSS1,AVSS2,EP which are connected to A_GND1? If not, please let me know which pins you are referring to. 

Yes, we can see example of A and D grounds in the datasheet for the device: 

And also, the way that you would be measuring your single ended outputs will need a ground, make sure you are using analog ground as well.

Hi,

Yes, we thought of this previously, so in our design, we shorted A_GND1 and GND together. 

- This eliminated a background hiss while audio was not playing. 

- But the noise while audio is playing remained unchanged. 

Note in addition to just scoping the line out signal, we are also outputting the single-ended outputs to an external amplifier, and can hear all the noise with the audio. 

Hi,

I mean adding A_GND1 instead of GND to your AVDD, DRVDD, and audio signal connections. Of course analog and digital ground need to come together to be connected, but they should come together at a central point like underneath the chip. 

Another note is do you still see the noise when you do not have the amplifier connected? Or do you still hear the noise when you are not scope connected to the line out? Maybe some impedance/noise problems with these two connections at once.

Best,
Mir

Hi Mir,

We'll check this out in detail. To help us out, could you share the Gerbers for the EVM board (TLV320AIC3104EVM) so we can check exactly how the grounds were done? And we're not sure how the Digital and Analogue grounds would come together under the codec. Would be helpful to see with gerbers of the EVM PCB.

Thanks

Hi,

Attached are the board files I have, there are Altium files. You can also find the EVM schematic/layout in the EVM user guide: https://www.ti.com/lit/ug/slau218a/slau218a.pdf

6487966G.zip

Best,
Mir