TAC5212: Linux Driver for 6.6 kernel

Hello,

You should use the ti.com download or git.ti.com driver. About the kernel I can have our driver developer comment.

Best,

Garret

Thanks, P.S : FWIW is a bug in the master branch for I2S. No no audio on right channel can be fixed by:

1. 0x1F is set to 0x01, must be 0x10 (for TX , ADC, CH2)
2. 0x29 is set to 0x21, must be 0x30 (for RX, DAC, CH2)

At 8Khz ok, but still get an speaker-test Input/Output error after about a second at other data rates. (the IMX93 seems to only support 8/16/48/96) ,after that error, 8K also gives I/O error. Need to reboot to get it back to work at 8K

root@imx93frdm:~/test/emmc/audio# speaker-test -c 2 -D hw:0,0,0 -r 48000 -f 440 -t sine
speaker-test 1.2.11
Playback device is hw:0,0,0
Stream parameters are 48000Hz, S16_LE, 2 channels
Sine wave rate is 440.0000Hz
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 32 to 131072
Period size range from 16 to 8184
Periods = 4
was set period_size = 8184
was set buffer_size = 32736
 0 - Front Left
Write error: -5,Input/output error
xrun_recovery failed: -5,Input/output error
Transfer failed: Input/output error

1] Sorry for the confusion. The only repo which is being actively maintained by TI is 

     https://git.ti.com/cgit/lpaa-android-drivers/tac5x1x-linux-driver/

• tac5x1x_driver - for 6.x and 7.x versions
• tac5x1x_driver_5.10 - for kernel version 5.10 
• tac5x1x_driver_5.15 - for kernel version 5.15

    dev branch are customer specific branches and are old.

    master and 4.14 I think are older ones. I will work internally to 

2] Regarding the IO error, it will be DMA related issue and not related to codec driver. 

with 6.6.36 and the tac5x1x-driver branch the following errors occur

sound/soc/codecs/tac5x1x-i2c.c:518:15: error: implicit declaration of function ‘regmap_multi_reg_read’; did you mean ‘regmap_multi_reg_write’? [-Werror=implicit-function-declaration]
  518 |         ret = regmap_multi_reg_read(tac5x1x->regmap,
      |               ^~~~~~~~~~~~~~~~~~~~~
      |               regmap_multi_reg_write
sound/soc/codecs/tac5x1x-i2c.c: In function ‘tac5x1x_add_widgets’:
sound/soc/codecs/tac5x1x-i2c.c:2167:17: error: implicit declaration of function ‘snd_soc_component_to_dapm’; did you mean ‘snd_soc_component_get_dapm’? [-Werror=implicit-function-declaration]
 2167 |                 snd_soc_component_to_dapm(component);
      |                 ^~~~~~~~~~~~~~~~~~~~~~~~~
      |                 snd_soc_component_get_dapm

Sorry for the trouble, I will fix these issues in a new 6.6 branch and updated the repo.

This is pretty much the biggest nightmare with linux drivers. When patches are released for newer kernal that replace older code, for CVE, but the platform suppliers and Yocto code is far behind in backporting, so the compile  on updated driver occur. 

I can't find the older code to patch the snd_soc_component_to_dapm’ that seems to fix a  CVE for the rt1011 driver

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=30e4b2290cc2a8d1b9ddb9dcb9c981df1f2a7399

For the other issue this I found for the 5.10 driver

        #if LINUX_VERSION_CODE < KERNEL_VERSION(6, 11, 0)        
	ret = regmap_multi_reg_read(tac5x1x->regmap,
				    tac5x1x->irqinfo.latch_regs,
				    tac5x1x->irqinfo.latch_data, latch_count);
        #else
       	ret = tac5x1x_read_latch_registers(tac5x1x);
        #endif

1072.tac5x1x-i2c.c

Attache the driver with hacks. Not sure they are correct. Added comments in the code. Reasons are:

The driver loads at works but still at 8Khz sampling rate only, not unexpectedly , the same I/O error occurs 

[1] snd_soc_component_to_dapm introduced in kernel 6.17 due to CVE 

Commit Date: September 18, 2025 (merged during the v6.17 cycle
Author: Kuninori Morimoto
File Location: Defined inside include/sound/soc-component.h.
Workaround: Gues to use "get" instead of "to" call (I could not find the older code)

nvd.nist.gov/.../CVE-2026-43478  

[2] The regmap_multi_reg_read() function was officially introduced to the mainline Linux Kernel in July 2024 as part of the Linux v6.11 development cycle.

Workaround: apply the code from 5.10 kernel, bit there is a u16 to u8 conversion that may not be correct.

https://lkml.iu.edu/hypermail/linux/kernel/2407.1/03035.html

I wonder if it may be useful that when updating a kernel to keep the older code in comments or with with a f KERNEL_VERSION (even using comments), so that BSP that not have been back-ported and fail compilation can still use the older code. ? The ALSA code stack of  seem to break so very often.  Thank you for adding a 6.6 Kernel branch, the current errors were related to 6.17 and 6.11 changes, Perhaps for v6 is is easier to maintain a #IF KERNEL_VERSION  statement ? For example  for v5.10 and 5.15 use a v5 driver with #IF KERNEL_VERSION switches and for v6,and  stable v7 the same. So that there is just one file for each kernel generation, while master is based on the latest Linus unstable release ?

Thanks for the suggestion. If we have a new case like that, I think I will use this approach to avoid multiple branches. 

I used the linux-driver branch driver to NXP the kernel 6.18.20 and it loads, but it gives the famous -5 Input/Output error. the same as in this post for IMX8. The SOC does output the BCLK and FS clock correc frequencies but ALSA fails, With the IMX93 only 48000 and 96000 are supported.  it seem related to  tac5x1x_hw_params or tac5x1x_set_dai_fmt  8K/16/11.025/22.050/44100 ALSA reports it cannot set the sampling rate. In the codec driver there are some DAI calls. Could this cause issues ? Attached are some files. maybe it can help to figure out the cause ?

https://community.nxp.com/t5/i-MX-Processors/Configure-TLV320AIC32x4-I2C-Codec-with-I2S-over-SAI/m-p/2359391

The platform manufacturers sometimes point to that the codec supplier must provide a  "codec driver" and vice versa. if I understand correctly, the code driver only need to support the set the sampling rate and optional mixer controls. if the settings are wron it could cause wrong or no audio output, but should not cause an Input/Output error, when the codec in clock slave mode, For my case (IMX93/TAC5212) I am afraid the support will be the same. Most platform supplier test only one codec for the dev-kit and from there  there isn't any support. Even not for latest kernels or latest codecs. How to get out of this vicious circle ? What is the missing piece for the TAC5212 ? I have now tested two MPU platforms and one of them was proven the soc driver was at fault (but still issue at higher sampling rates) and on IM93 it has to be seen if there will be sufficient support to get beyond this show-stopper.

kernel_6-18-20-tac5x1x-codec-logs-260812.zip

Thank you very much . I  have a few updates as well

1. tried before to make a dummy drive but failed to compile, will look at this link

2. Used the TAC 6.6 branch and compiled in 6.6.36 kernel without errors (same speaker-test I/O error and sample rate error exists)

3. I plan add debug message in the driver to see if it there is any TAC driver error. I don't see anything in DMESG so far.

Work with NXP FAE continues but so far no progress. I wonder there is something related to the DAI or Machine driver. 

1. for the dummy driver, I would like to know how to add that to the DT, I have in the root

     sound-ext-i2s {
		compatible = "fsl,imx-audio-card";     
		model = "linux,ext-i2s";
		status = "okay";
		pri-dai-link {
			link-name = "ext-i2s-codec";
			format = "i2s";
			cpu {
				sound-dai = <&sai3>;
			};
			codec {
				sound-dai = <&exti2s>;
			};
		};
     };

and as the device node for i2c

	exti2s: audio-codec@51 {
		#sound-dai-cells = <0>;  
		compatible = "linux,ext-i2s-codec";
		reg = <0x51>;
	};

but the result from dmseg is:

[   20.355617] platform sound-ext-i2s: deferred probe pending

2. Regarding the debug messages for the hwconfig:

8k works

48K I/O error -5

44.1K , format error, for example:

Stream parameters are 44100Hz, S16_LE, 2 channels
Sine wave rate is 440.0000Hz
Rate set to 44100Hz (requested 44100Hz)
Buffer size range from 32 to 131072
Period size range from 16 to 8184
Periods = 4
Unable to set hw params for playback: Invalid argument
Setting of hwparams failed: Invalid argument

dmesg log:

[ 10.366897] tac5x1x-codec 4-0051: Loopback controls added
[ 10.380379] tac5x1x-codec 4-0051: tac5x1x_set_dai_fmt: SND_SOC_DAIFMT_CBP_CFC
[ 10.380399] tac5x1x-codec 4-0051: tac5x1x_set_dai_fmt: SND_SOC_DAIFMT_I2S
[ 10.907281] tac5x1x-codec 4-0051: ADC-to-DAC loopback disabled
[ 10.907300] tac5x1x-codec 4-0051: Loopback disabled
[ 11.034606] tac5x1x-codec 4-0051: ADC-to-DAC loopback disabled
[ 11.034624] tac5x1x-codec 4-0051: Loopback disabled
[ 618.526872] tac5x1x-codec 4-0051: tac5x1x_set_dai_fmt: SND_SOC_DAIFMT_CBP_CFC
[ 618.526890] tac5x1x-codec 4-0051: tac5x1x_set_dai_fmt: SND_SOC_DAIFMT_I2S
[ 618.527098] tac5x1x-codec 4-0051: tac5x1x_hw_params: rate = 44100
[ 618.527105] tac5x1x-codec 4-0051: tac5x1x_hw_params: width = 16
[ 623.891039] tac5x1x-codec 4-0051: tac5x1x_set_dai_fmt: SND_SOC_DAIFMT_CBP_CFC
[ 623.891058] tac5x1x-codec 4-0051: tac5x1x_set_dai_fmt: SND_SOC_DAIFMT_I2S
[ 623.891082] tac5x1x-codec 4-0051: tac5x1x_hw_params: rate = 8000
[ 623.891089] tac5x1x-codec 4-0051: tac5x1x_hw_params: width = 16
[ 638.810822] tac5x1x-codec 4-0051: tac5x1x_set_dai_fmt: SND_SOC_DAIFMT_CBP_CFC
[ 638.810840] tac5x1x-codec 4-0051: tac5x1x_set_dai_fmt: SND_SOC_DAIFMT_I2S
[ 638.810865] tac5x1x-codec 4-0051: tac5x1x_hw_params: rate = 48000
[ 638.810872] tac5x1x-codec 4-0051: tac5x1x_hw_params: width = 16
[ 644.834765] tac5x1x-codec 4-0051: tac5x1x_set_dai_fmt: SND_SOC_DAIFMT_CBP_CFC
[ 644.834784] tac5x1x-codec 4-0051: tac5x1x_set_dai_fmt: SND_SOC_DAIFMT_I2S
[ 644.834809] tac5x1x-codec 4-0051: tac5x1x_hw_params: rate = 44100
[ 644.834817] tac5x1x-codec 4-0051: tac5x1x_hw_params: width = 16

and a soc error for unsupported format, but the tax5x1x driver seems to return 0

 fsl-sai 42660000.sai: ASoC: error at snd_soc_dai_hw_params on 42660000.sai: -22

An issue was identified with the platform driver. the platform driver uses some customized code to initialize it's PLL .

The platform driver code link->codecs->dai_name picks up the TAC5212 codec as taa5x1x-hifi-04-51. (bus 4, I2C address 0x51)

seen the tac5x51 driver code  dai->name = devm_kasprintf(dev, GFP_KERNEL, "taa5x1x-hifi-%02x-%02x",    i2c->adapter->nr, i2c->addr); for many different model the name is set.

1. Perhaps the constant ("taa") could cause wrong initialization by platform drivers ?

2. Why is this naming format chosen ?

3. aplay -l  shows an extra "0":   card 0: titac5212 [ti,tac5212], device 0: tac5212 taa5x1x-hifi-04-51-0 [tac5212 taa5x1x-hifi-04-51-0]

[3] it is set to 0.  Perhaps it's ALSA adding  this for the card#. 

We have not been able to resolve all the problem with the platform provider. Though after making changes to the platform driver, 48K and 96k are now working from the BLK/FS side. But the analog output is like a square wave. Any idea what this could be .? it does not seem that the volume or gain setting cause this.

Hello,

What is the level of audio input being played? Can you send the register dump?

Best,

Garret

I noticed reg 0x65 an 0x66 are set to 0x08 instead of 0x20. This sets a reserved bit in OUT1M_LVL_CTRL[2:0] and OUT1P_LVL_CTRL[2:0]. The script below should set it to 0x20 but it does not.  (diff line out, 0db). This applies to 0x6C and 0x6D as well. Setting the I2C register with i2set and then using speaker-test or  my custom PCM ALSA code, after playback for both tools the registers are set reset back to 0x08.

I compared the driver 5.10 and 6.6 code and don't see much difference. Due to high level of macro's in  the driver it a bit hard to figure out where the values for these register are set and when. Or, perhaps something else is overwriting the values.

Using ALSAMIXER and selecting headphone as output, then exits it and run 2cdump the register values stay at 0x08. When relaunching alsamixer, it  shows headphone, even the i2c register is  0x08. Perhaps I am missing something, but it looks like the ALSA state and the i2c register state do not match. Maybe ALSA keeps it state somewhere. The driver or ALSA may not read back the actual state of the CODEC for initializing the mixer values  or reading them back the check if the values were correctly set ? As the driver relies on regmap and does not check on errors ? Perhaps this may have something to do with remap of the platform ?

amixer -c 0 cset iface=MIXER,name='ASI_RX_CH1_EN Switch' on
amixer -c 0 cset iface=MIXER,name='OUT1x Config' 'Differential'
amixer -c 0 cset iface=MIXER,name='OUT1x Driver' 'Line-out'
amixer -c 0 cset iface=MIXER,name='OUT1x Source' 'DAC Input'
amixer -c 0 cset iface=MIXER,name='ASI_RX_CH2_EN Switch' on
amixer -c 0 cset iface=MIXER,name='OUT2x Config' 'Differential'
amixer -c 0 cset iface=MIXER,name='OUT2x Driver' 'Line-out'
amixer -c 0 cset iface=MIXER,name='OUT2x Source' 'DAC Input'

Register 0x65/0x66/0x6C/0x6D
7 6  5 4 3  2 1 0 bits
0 0  1 0 0  0 0 0 expected line out & 0 db
0 0  0 0 1  0 0 0 actual b3 reserved = 1

When we run the mixer controls, when the device is in suspend mode, the device will be in low power mode with regmap in cache only mode. So only the regcache is updated. So i2cdump will not have the updated registers.

When some events like playback happens, the driver will resume and regcache_sync ( snd_soc_component_cache_sync ) will happen and should restore the actual register values - the dump should have the updated registers, after the device resumes. Is this not happening ? If not please let us know, I will take a look tomorrow. 

Thanks, I tried this: alsamixer change settings -> play audio -> read I2C

[1] OUT1P_DRIVE: : i2cdump values do not match Alsamixer setting in 0x66 and 0x6D, but 0x65 and 0x6C did update. (see file attached) osc is my custom PCM playback tool, the result is the same with ALSA speakertest. After this , running alsamixer again it shows the same values as set in alsamixer before audio playback.

[2] OUTP1X_LVL_CTRL it seems there isn't an Alsamixer control .it's fixed to the reserved value of 1 (x08) so it cannot be changed via regmap suspend/resume. Perhaps this explains the square wave output if the output is clipped.But how can be value (default?) for this register 0x08 and sets a reserved bit?

BTW this is the kernel 6.6 branch.

root@imx93frdm:~/test/tac5212# i2cdump -f 4 0x51
No size specified (using byte-data access)
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-4, address 0x51, mode byte
Continue? [Y/n] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 00 00 00 00 00 15 f0 00 00 00 40 10 00 00 00 00    .....??...@?....
10: 51 80 00 00 00 00 00 00 40 00 40 00 00 00 00 10    Q?......@.@....?
20: 02 03 04 05 06 27 00 00 20 30 30 30 04 65 66 67    ?????'.. 000?efg
30: 00 00 00 00 40 c0 00 20 00 00 00 00 00 00 00 00    ....@?. ........
40: 00 00 11 54 00 00 00 00 00 00 00 00 2e 0c 00 00    ..?T.........?..
50: 04 00 f0 f0 f0 04 00 f0 f0 f0 00 f0 f0 f0 00 f0    ?.????.???.???.?
60: f0 f0 00 00 20 48 08 f1 b0 f1 b0 20 48 08 f5 c0    ??.. H????? H???
70: f4 c0 18 98 00 00 00 e0 00 00 80 00 c0 10 f1 00    ????...?..?.???.
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
root@imx93frdm:~/test/tac5212# ./osc 2 440 48000 10 S16LE  1024 hw:0,0,0
osc <channels> <frequency> <sample_rate> <duration> <format> <frames>
formats: S16LE, S24LE, S32LE
frames is number of frames per pcm write transaction
blocks is the number of pcm transfers (based on the requested duration)
channels=2 frequency=440.000, rate=48000, duration=10, format=S16LE, frames=1024
using  device hw:0,0,0
Format is 16 bits
root@imx93frdm:~/test/tac5212# i2cdump -f 4 0x51
No size specified (using byte-data access)
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-4, address 0x51, mode byte
Continue? [Y/n] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 00 00 00 00 00 15 f0 00 00 00 40 10 00 00 00 00    .....??...@?....
10: 51 80 00 00 00 00 00 00 40 00 40 00 00 00 00 10    Q?......@.@....?
20: 02 03 04 05 06 27 00 00 20 30 30 30 04 65 66 67    ?????'.. 000?efg
30: 00 00 00 00 40 c0 00 20 00 00 00 00 00 00 00 00    ....@?. ........
40: 00 00 11 54 00 00 00 00 00 00 00 00 2e 0c 00 00    ..?T.........?..
50: 04 00 f0 f0 f0 04 00 f0 f0 f0 00 f0 f0 f0 00 f0    ?.????.???.???.?
60: f0 f0 00 00 20 88 08 f1 b0 f1 b0 20 88 08 f5 c0    ??.. ?????? ????
70: f4 c0 18 98 00 00 00 e0 00 00 80 00 c0 10 cb 00    ????...?..?.???.
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
root@imx93frdm:~/test/tac5212# 

Could you please try with the values ?

amixer cset name='OUT1P Analog Level Playback Volume' 2

amixer cset name="OUT2P Analog Level Playback Volume" 2

Booted up the device, an ran that. The reserved bit is cleared. I am not sure if was cleared before that.However using the follwing command with value 3 and after running speaker test the register is 0x18. which thus sets the reserved biut.  Volume set to 2 does clear it after spealker test. Perhaps there is mask in the macros incorrect as setting a reserved bit should not be possible. After a power cycle of trhe device the bits stay the same, does the TAC save it settings in Non volatile memory?  

amixer cset name="OUT2P Analog Level Playback Volume" 3

After setting the value to 0x20 (0 dB) ,  the analog output still shows the square wave. with the volume set to 1 the amplitude is only reduced to 1.72Vpp while it's still a sqaure wave

Here are the result and observations

Config: Line out differential, I2S, 48Khz

Procedure used to avoid no analog output:
1. Set digital and analog gain , 2x
2. Start speaker-test (it seem to try to start but then stops analog output)  (*)
3 CTRL Break speaker test
4. Set digital and analog gain ,again, 2x
5. start speaker-test (now there is a signal)

6. stop and start speaker-test , no signal => go back to step 1

(*) UPDATE: confirmed that when there is no analog output, the BLCLK, DATA and FS data are all there. 

(**) UPDATE #2: another clue found: after stopping speaker-test and then wait about 5 seconds and starting it, the analog output is back. But, when waiting for around 10 seconds it sometimes does not. it seem this may have something to do with power management ? On another platform with the same TAC5212 board, this issue does not occur. i did observer before that the TAC5212 driver entered after 5 seconds or so a power management routine that had a switch() and returned , break,, without doing anything.

in summary

1. Stop speaker-test

2. restart within  5 seconds => no output,

3. restart after around 5 seconds => output

4. restart after 10 seconds => sometimes output , sometimes not.

Goto step 1

Observations:
1. Range for usable max to min is 172~206 around 40 steps out of 0~256 tange
2. When channel is not playing (but the other does) the noise is quite high
3. Speaker test seem not drive volume at maximum (OSC tool uses maximum values)
4. There is no analog output unless using the specific steps above to get analog output

Is there any difference in the register map between cases? What are the AVDD and VREF voltages when there is no output?

Results as attached,  when "no sound" therei s about 0.25sec sound but then stops. Register differences:

Register   Sound    no sound    difference

0x3e         0x50          0x00        sample rate no sound = 0. with sound = 20d = 48000

0x41         0x20          0x00       primary ASI or secondary ASI FSYNC to clock source ratio detected.

0x43         0x54          0x5C      DAC_FLT_CFG, interrupt configuration register.

0x79         0x0xC        0x00      device status value register 0. (no sound: DAC ch1/2 is powered down)

0x7a         0xF0          0xC0      no sound: Device active but playback channels turned off

0x7e         0xF6          0x0A      checksum

AVDD Sound : 3.318V, no sound: 3.315V

with sound , VREF=2.740V
-----------------------

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 00 00 09 00 00 15 f0 00 00 00 40 10 00 00 04 00    ..?..??...@?..?.
10: 51 80 00 00 00 00 00 00 40 00 40 00 00 00 00 10    Q?......@.@....?
20: 02 03 04 05 06 27 00 00 20 30 30 30 04 65 66 67    ?????'.. 000?efg
30: 00 00 00 00 40 c0 00 20 00 00 00 00 00 00 50 00    ....@?. ......P.
40: 80 20 11 54 00 00 00 00 00 00 00 00 2e 0c 00 00    ? ?T.........?..
50: 04 00 f0 f0 f0 04 00 f0 f0 f0 00 f0 f0 f0 00 f0    ?.????.???.???.?
60: f0 f0 00 00 20 20 20 c8 b0 c8 b0 20 20 20 c8 c0    ??..   ????   ??
70: c8 c0 18 98 00 00 0c e0 40 0c f0 00 c0 10 f6 00    ????..??@??.???.
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

no sound  VREF=2.740V
------------------------

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 00 00 09 00 00 15 f0 00 00 00 40 10 00 00 04 00    ..?..??...@?..?.
10: 51 80 00 00 00 00 00 00 40 00 40 00 00 00 00 10    Q?......@.@....?
20: 02 03 04 05 06 27 00 00 20 30 30 30 04 65 66 67    ?????'.. 000?efg
30: 00 00 00 00 40 c0 00 20 00 00 00 00 00 00 00 00    ....@?. ........
40: 00 00 11 5c 00 00 00 00 00 00 00 00 2e 0c 00 00    ..?\.........?..
50: 04 00 f0 f0 f0 04 00 f0 f0 f0 00 f0 f0 f0 00 f0    ?.????.???.???.?
60: f0 f0 00 00 20 20 20 c8 b0 c8 b0 20 20 20 c8 c0    ??..   ????   ??
70: c8 c0 18 98 00 00 0c e0 40 00 c0 00 c0 10 0a 00    ????..??@.?.???.
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

It seems there is once again a clocking error that is causing the power down of the DAC channels.

From where that can be concluded ? Anything specific to look for ? As playback sometimes it works and sometimes not. But this is hard reproducable   This is quite difficult to nail down exact moment when it works and when by looking at I2S signals. It seems some timing related issue when clocks re-starts after a stop.  I measure the FS, BCLK  in both situations and they seem fine. What "clocking error" could this be ?