Signal distortion on the audio codec's headphone out

I have a Dahlia v1.1B board with the Verdin iMX8M Mini Quad 2GB WB IT V1.1B based. The image used is your Linux Multimedia Reference 5.6.0+build.18 . The audio signals from the “AAP_HP_CON L/R” output (connector X14) are distorted and the amplitudes from right and left channel are differents.

Your image comes with some audio files for testing. When testing with the 440hz_10s.wav file, it is observed that the right channel sounds louder than the left and also the right channel seems to have some kind of distortion. In this link you can find an audio file that allows you to better test what I say. I am using aplay to play the audio files.

I have tried with several WAV type audio files and the problem is always the same, the right channel is heard louder and the audio is distorting. I have tried modifying the alsamixer parameters and have not found any set of values that makes this unwanted effect go away. I have also tried with different headphones and the problem does not go away.

I hope someone can help me.

Thanks,
Julián

Dear @jbruno, how are you?

Thanks for reaching out. Could you please share with us the following information in order to better understand your issue?

  • Did you do any changes to the image or is it our pre-built one?
  • Which Kernel are you using? Downstream or upstream?
  • What is the output of the following command on your module fw_printenv fdt_board? This is important to know as by default, the Verdin images come configured to use the Development Board Device Tree and it uses a different codec.

Best regards,
Guilherme

Hi @gclaudino.tx ,
Thank you very much for your quick response. I answer between the lines.

  • Did you do any changes to the image or is it our pre-built one?

The only change has been that we have interrupted the u-boot and set the fdt_board variable with the value dahlia as follows: setenv fdt_board dahlia and then saveenv

  • Which Kernel are you using? Downstream or upstream?

Linux verdin-imx8mm-06902246 5.4.161-5.6.0+git.0f0011824921 #1 SMP PREEMPT Fri Mar 25 14:27:29 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux

*What is the output of the following command on your module fw_printenv fdt-board ?

I use the variable fdt_board because Rafael Beims indicated. I don’t know I think this affects the audio performance.
fdt_board=dahlia
During boot this output is observed:
[ 0.000000] Machine model: Toradex Verdin iMX8M Mini WB on Dahlia Board

Best regards,
Julian

Thanks for the fast reply @jbruno,

The - was a typo in my previous message. I edited it to show the right one.

As I said before, the development board and dahlia use different codecs so if you’re using the wrong codec you’d experience problems with it but it seems that Rafael instructed you well about changing the device tree already.

Could you please share with us the full dmesg log? We’ll try to reproduce it on our side in the meantime.

Best regards,

Attached the log file.
dmesg.log (26.5 KB)
Thank you very much for your help.
Best regards,

Hi @gclaudino.tx ,
I have connected the oscilloscope to measure the signals from connector X14 while playing the audio file 440hz_10s.wav. Scope channel 1 displays the codec right channel and scope channel 2 displays the codec left channel. To my knowledge, in the capture of the oscilloscope you can clearly see that the signal of the right channel (ch1) is distorted by a misinterpretation of the numerical format.

I am attaching a file with the ALSA configuration.
alsa_conf.txt (5.2 KB)

I hope someone can help me.

Thanks,
Julián

Hi @jbruno,

We’re currently investigating this behavior internally as we could reproduce it here. Do you have other modules or carrier boards where you could reproduce it? We’ll come back to you once we have more news on the topic.

Best regards,

Hi @gclaudino.tx
I have tried on several Dahlia boards and with different Verdin modules, even with all versions of the linux multimedia reference image. The error is always the same, the MSB of the right channel is misinterpreted.

From the tests we’ve been doing, everything seems to point to an error in the i2s configuration, although we can’t confirm it yet. The WM8904 supports 4 different audio formats, which mode do you use? We have captured the i2s signals with a logic analyzer and it seems that you are using DSP Mode Audio Interface (mode A, AIF_LRCLK_INV=0, Master).

I await your news.

Best regards,

Dear @jbruno,

Thanks for the update. I’ve sent this to our team and we’ll come back once we have any news on it.

Please also keep us aware if you have any news on this topic.

Best regards,

Dear @gclaudino.tx

We have been analyzing the configurations of the audio codec and the i2s of the imx8mm that you make. From this analysis it can be deduced that both devices have been configured to work in I2S Justified Audio Interface mode (see figure 47 of the codec manual) but when measuring the I2S signals with the oscilloscope it seems that the imx8mm is transmitting in DSP Mode Audio Interface mode A format ( see figure 48 of the codec manual).

According to your configuration you are using a BCLK 34 times faster than the LRCLK, and since 32 bits are transmitted, two cycles of BCLK remain unused. In I2S Justified Audio Interface mode, these unused BCLK cycles between the LSB of one sample and the MSB of the next. In DSP Mode Audio Interface, these unused BCLK cycles between the LSB of the right channel data and the next sample.) The audio codec expects data in the first format but receives it in the second format and is for this reason it always misreads the MSB of the right channel.

We have done tests with a wav file that contains a square wave form, which only has two possible values ​​(0x7D and 0x83) that are repeated in time in both channels. Below I show some captures with the oscilloscope where you can see that the audio samples are transmitted in the DSP Mode Audio Interface format (mode A, AIF_LRCLK_INV=0, Master).

square 0x83 i2s - LRch.bmp (1.1 MB)
square 0x83 i2s - Rch.bmp (1.1 MB)
square 0x83 i2s - Lch.bmp (1.1 MB)

Below I show a scheme of my interpretation of the measurements made.

I don’t understand why the imx8mm is transmitting the audio samples in DSP format when it is configured to work in i2s format, has NXP reported this bug? In which format does the audio codec of your Verdin Development Board expect to receive the audio samples? Have you checked if this right channel distortion error is present on your card at the Verdin Development Board?

I await your news.

Best regards,

Dear @jbruno,

Thanks for the update. This will indeed be very useful for us to debug this behavior.

About that point:

I tested the same audio file on the Development Board and could get any distortion on my earphone as I experienced on the Dahlia. I didn’t have an oscilloscope with me, however. In any case, this doesn’t seem to happen on the Development Board. The Development Board uses a different codec than the Dahlia.

Best regards,

Dear @gclaudino.tx ,

I have it clear. The suspicion I have is that it is not the fault of the audio codec that misinterprets the data, but rather that it is the fault of the imx8mm that sends the data in the wrong format. If so, it could also fail on the Verdin Development Board.

Best regards,