SGTL5000 CODEC line-in noise on i.MX28

[CraigMcQueen]

We are developing a system based on i.MX28, which does audio input and output through the SGTL5000 CODEC.

Our software works fine most of the time, however, sometimes after boot-up (maybe 10-20% of the time) the audio input via SGTL5000 ADC_IN is very noisy. It persists even if I stop and restart audio input. (Normally the software is doing two-way audio streaming, but I also get the same sort of noise via 'arecord test.wav'.) If I power cycle the unit, then usually audio is fine after the power cycle.

We're using the Linux 2.6.35 kernel. The problem occurred both before and after applying the Freescale patches "patches_for_L2.6.35_MX28_SDK_10.12_SOURCE.tar.gz".

The noise sounds as though it's due to a gain setting that is sometimes starting up in an indeterminate state, with a higher gain setting than "normal". Sometimes it sounds like bad clipping of the input, when gain is set too high. Sometimes it sounds like plain noise, regardless of the input.

I tried compiling the kernel audio drivers as a module, and loading/unloading via "modprobe" command. When the problem occurs, it persists even if I do "modprobe -r" then "modprobe" to reload the audio driver.

It looks as though it might be some sort of issue with the SGTL5000 CODEC coming up in an indeterminate state for some register settings, and the Linux SGTL5000 driver doesn't fix it.

Has anyone else seen this issue?

Is there an easy way I can see a dump of all SGTL5000 register settings with/without this noise issue present, to test my hypothesis?

[fabio_estevam]

Hi Craig,

Please apply the four patches from Jack Lee available at:

http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=imx_2.6.35_maintain

Regards,

Fabio Estevam

[CraigMcQueen]

I've recently been trying the imx_2.6.35_maintain branch of Freescale's repository. I'm finding problems with Jack Lee's patches—maybe they fix the noise issue, however they also introduce other problems: it's not possible to playback and record at different sample rates. E.g. using aplay and arecord:

In one terminal:

# aplay testing_1_2_3_4_repeated.wav

Playing WAVE 'testing_1_2_3_4_repeated.wav' : Signed 16 bit Little Endian, Rate 8000 Hz, Mono 

while in another terminal:

# arecord -r 16000 /tmp/test.wav

Recording WAVE '/tmp/test.wav' : Unsigned 8 bit, Rate 16000 Hz, Mono 

The arecord doesn't show any error messages, however it doesn't get any audio data. The file /tmp/test.wav is just 44 bytes.

I'm using a somewhat modified sound driver, due to the hardware we're using which is based on SGTL5000 but with some changes. I modified my code to match up with these patches, namely, duplicating a change in the ALSA SoC machine driver of sound/soc/mxs/mxs-devb.c — and I'm still having this issue.

If I record at the same sample rate as the play, then it is okay.

[CraigMcQueen]

Do you have any further advice on this issue of not getting any audio data when trying to play and record at different audio sample rates? We are still sometimes getting audio noise on line-in, and can't use the latest patches because they don't work for different playback and record audio sample rates. What do you advise?

[PeterChan]

Hello Craig,

Unfortunately, audio playback & recording simultaneously at different sampling rates is not one of our test cases.

Could you please describe your connection between SAIF and the SGTL5000? On i.MX28 EVK, audio playback and recording are sharing the same I2S_LRCLK and I2S_SCLK pins which are driven by the SAIF0. It is because the audio recording signal SAIF1_SDATA0 (SGTL5000 I2S_DOUT) is driven the clocks generated from SAIF0, synchronization problem will occur if the SAIF0 & SAIF1 are configured at different sampling rates or data formats.

Unless your hardware has separate I2S_SCLK & I2S_LRCLK pins for both SAIFs to audio codec(s), otherwise the sampling rate & data format must be the same for simultaneous playback and recording.

[fabio_estevam]

My understanding is that when the two SAIF ports are used (one as master and other as slave) they need to be at the same sampling frequency.

From the mx28 reference manual (35.2.1):

"Also, one of the two SAIFs can master or drive the clock pins while the other SAIF, in slave mode, receives clocking from the master SAIF. This also means that both SAIFs must operate at the same sample rate."

[CraigMcQueen]

I'm retesting and finding that my previous report regarding sample rates seems to be incorrect. I must have misinterpreted the circumstances under which the problem occurs.

Retesting, I'm finding the following:

• If aplay is started, and arecord is started either while aplay is running or after it has finished, then arecord gets no audio data.
• If aplay is started while arecord is frozen, then arecord begins to get audio data, and continues to do so after aplay stops.
• Once arecord is getting audio data, then it can be started and stopped successfully many times, and will continue to work. But if aplay is started when arecord isn't running, then subsequent arecord will again fail to get any audio data.

[PeterChan]

Hello Craig,

May I have your steps to reproduce this recording issue?

Thanks,

Peter

[CraigMcQueen]

I have been running aplay and arecord commands in two separate SSH terminals. aplay to play a WAV file (something like a 5 second file at 32 kHz). arecord to record input audio to a WAV file (try 8 kHz or 32 kHz using -r option).

Try running aplay, and then after it finishes, run arecord. You may find that arecord doesn't get any audio data, so the resulting WAV file is just 44 bytes (file header data only).

Try running aplay, and start arecord while aplay is in-progress.

Try running arecord first, and then start aplay. I found (by looking at recorded file size) that arecord wouldn't get any audio data at first, until aplay started--then it would get audio data. Then, if arecord is stopped after aplay stops, subsequent arecords work fine. But then if aplay is run by itself, subsequent arecords don't get data.

[PeterChan]

Hello Craig,

This morning I did the same test (recording.sh & playback.sh) on BSP L2.6.35_1.1.0_130130 but I still cannot reproduce this recording issue. The following 4 patches are applied to the kernel image that I tested.

Please let me know the detail reproducing steps if the recording problem still persists.

Thanks,

Peter

[CraigMcQueen]

As I said previously, we have a configuration that seems reliable. However, we would still like to follow-up on a few points.

Our reliable configuration excludes these three patches:

• 90ce77d4468e2fe4a52aaaad1360782bc1bd6696 ENGR00285446-3 [MX28] SAIF: Bit Shift in SAIF RX Data
• 1ea685a12f196ce253ef6387f27c912927312ced ENGR00285446-2 [MX28] SAIF: Bit Shift in SAIF RX Data
• 1ca899221d8b100db68c336b5568a6e1d4042b20 gENGR00285446-1 [MX28] SAIF: Bit Shift in SAIF RX Data

Excluding these, we still had approx 1/50 failures. We had to apply the equivalent of the following patch to the kernel driver for our board:

• b3912bb8a4caf3ec50909135e88af959982c43ca ENGR00285448 [MX28] SAIF: Out of Voltage in SAIF clock PINs

We merged this change into our equivalent file. We found that the occasional (1/50) noise problem disappears.

We would like to understand the underlying cause. Hence our questions:

• What is the failure mechanism that causes occasional (1 out of 50) input noise if the SAIF clock pins have the wrong configured drive strength?
• I assume there is a bit misalignment, effectively causing a word rotation where one or more LSbits are being regarded as MSbits. Is this bit misalignment in the SAIF or the SGTL5000? (I suppose it might be possible to use a logic analyser to answer that question.)
• Why is the SAIF/SGTL5000 (whichever it is) not resyncing on the frame sync signal, so that any bit misalignment is corrected on the next frame, making the noise issue a transient one?

We received the following answer from W Chong:

Using BSP without these patches, the SAIF0 and SAIF1 are driven by 2 different clock sources. They are ref_pll and ref_xtal respectively.

The audio output path (playback) is driven by the SAIF0 and the audio input path (recording) is driven by SAIF1. SAIF0 is also responsible to provide the MCLK and LRCLK to the SGTL5000 during audio playback & recording.

It is because the SAIF0 and SAIF1 are driven by 2 different clock sources, they may not always synchronized and bit misalignment will occur when synchronization between SAIF0 & SAIF1 lost.

The patch force both SAIF0 & SAIF1 to be driven by the same clock source ref_pll. Besides, soft reset is needed on both SAIF before modifying the SAIF control register based on chip design.

That makes some sense. However, the 3 patches seem to introduce another problem where the recording doesn't necessarily work until the playback is started. So we cannot use the 3 patches. Please see if you can reproduce the problem as I have described it in my previous message.

[英库李]

Hi Craig,

We are also persecuted by the audio noise and with no recording audio data once in a while. Have you gotten the root case?

[PeterChan]

Q1. What is the failure mechanism that causes occasional (1 out of 50) input noise if the SAIF clock pins have the wrong configured drive strength?

According to SGTL5000 spec, the driving strength of clock signals are only 4mA. The old code use 12mA drive strength for these signals and severe overshoot is observed at the rising edges of the SAIF clocks. The signal overshoot is a potential problem that cause the false data is latched.

Q2. Why is the SAIF/SGTL5000 (whichever it is) not resyncing on the frame sync signal, so that any bit misalignment is corrected on the next frame, making the noise issue a transient one?

This is explained in W Chong's answer. The syncrhonization between SAIF0 & SAIF1 is lost and SAIF1 is latching the false data at the incorrect timing.

Q3. Please see if you can reproduce the problem as I have described it in my previous message.

No, I am not able to reproduce the problem on the imx_2.6.35_maintain branch with these 3 patches. My steps is

1. Open a SSH terminal to i.MX28 and run "aplay test1.wav"

2. Open another SSH terminal to i.MX.28 and run "arecord -d 10 test2.wav"

3. After arecord ends, check the file size if it matches with the sampling rate x duration.

Please let me know if the above steps are correct or not.

[PeterChan]

Hello Craig,

I run the attached scripts on i.MX28 EVK in 2 separate SSH terminals. The first script records a 32kHz audio wav in the first terminal and the second terminal run the script to this wav file generated by the first terminal. I am not sure if I get the reproducing steps correct but so far both audio recording and playback looks good.

My kernel is the old BSP L3.0.35_10.12. If I made something wrong in the steps, would you please modify my scripts and send back the correct scripts (or steps) to me?

I will do the same test to BSP L2.6.35_1.1.0_130130 again.

Thanks,

Peter

[CraigMcQueen]

PeterChan wrote:

I run the attached scripts on i.MX28 EVK in 2 separate SSH terminals. The first script records a 32kHz audio wav in the first terminal and the second terminal run the script to this wav file generated by the first terminal. I am not sure if I get the reproducing steps correct but so far both audio recording and playback looks good.

Those scripts would mask the problem, because the beginning of aplay triggers the arecord to receive data. So I recommend rather than running these scripts both in a loop, you run the aplay and arecord manually, in the sequences I described in my earlier message. Each time, check arecord's output file length (using ls -l in another console) to see if it is recording data or not.

[CraigMcQueen]

My kernel is the old BSP L3.0.35_10.12. If I made something wrong in the steps, would you please modify my scripts and send back the correct scripts (or steps) to me?

I will do the same test to BSP L2.6.35_1.1.0_130130 again.

The problem I'm describing specifically affects three patches by Jack Lee, as Fabio Estevam recommended that I try:

Please apply the four patches from Jack Lee available at:

http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=imx_2.6.35_maintain

The three patches are:

• 90ce77d4468e2fe4a52aaaad1360782bc1bd6696 ENGR00285446-3 [MX28] SAIF: Bit Shift in SAIF RX Data
• 1ea685a12f196ce253ef6387f27c912927312ced ENGR00285446-2 [MX28] SAIF: Bit Shift in SAIF RX Data
• 1ca899221d8b100db68c336b5568a6e1d4042b20 gENGR00285446-1 [MX28] SAIF: Bit Shift in SAIF RX Data

Please try the 2.6.35 kernel that includes these patches, from the imx_2.6.35_maintain branch in the above Freescale git repository.

The other patch is okay:

• b3912bb8a4caf3ec50909135e88af959982c43ca ENGR00285448 [MX28] SAIF: Out of Voltage in SAIF clock PINs

Actually, we found that because we're using a different file for our target than the arch/arm/mach-mx28/mx28evk_pins.c, we were not including this change. So we merged this change into our equivalent file. Then we excluded the above three patches that are causing the "no input audio data" problem. We are finding that the occasional (1 out of 50) noise problem disappears. Further testing is required to confirm the reliability of that, but that may satisfy our reliability requirements.

My questions from that are:

• What is the failure mechanism that causes occasional (1 out of 50) input noise if the SAIF clock pins have the wrong configured drive strength?
• I assume there is a bit misalignment, effectively causing a word rotation where one or more LSbits are being regarded as MSbits. Is this bit misalignment in the SAIF or the SGTL5000? (I suppose it might be possible to use a logic analyser to answer that question.)
• Why is the SAIF/SGTL5000 (whichever it is) not resyncing on the frame sync signal, so that any bit misalignment is corrected on the next frame, making the noise issue a transient one?

[CraigMcQueen]

Yes, our hardware configuration of the SAIF <-->SGTL5000 connection is essentially the same as the imx28evk.

I will need to recheck the question of playback/record sample rates. I thought that the Linux audio drivers would enforce the playback/record sample rate constraints as needed by the hardware. I will retest and get back to you.

[fabio_estevam]

PeterChan may have some idea?

[ThomasBandelier]

Hi Craig, Peter,

We are running into same issue as you had. The provided patch also helped, but we still get the noise around 1 on 60 iterations.

Has any other patch been implemented for this ? I can not see any other activity related to this.

Peter, we are in discussion we technical support Jack Lee about this.

Waiting for your feedback,

Thomas

[fabio_estevam]

Thomas,

Could you please tell me how I can reproduce this issue? Is it possible to reproduce it via standard alsa utilities, such as aplay/arecord?

Could you try kernel 3.12-rc4?

Regards,

Fabio Estevam

[aidamynzhasova]

Hi Fabio,

I observe audio noise issue on mainline kernel, which is based on linux-next repository, master branch (last commit: 3a94271d0798fe2a2e5bfe2d135f2c8f6db2e80b).

I didn't make any changes, just built mxs-defconfig-based uImage and imx28-evk.dtb and loaded on my i.MX28 EVK REV D board.

After that I tried to record something:

~ # arecord -D hw:0,1 -t wav -c 2 -r 44100 -f S16_LE -d 5 awesome.wav

Recording WAVE 'awesome.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo

...and play it:

~ # aplay -D plughw:0,0 awesome.wav

Playing WAVE 'awesome.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo

I heard only random noise.

Here is the list of devices:

~ # aplay -l

**** List of PLAYBACK Hardware Devices ****

card 0: mxssgtl5000 [mxs_sgtl5000], device 0: HiFi Playback sgtl5000-0 []

  Subdevices: 1/1

  Subdevice #0: subdevice #0

~ # arecord -l

**** List of CAPTURE Hardware Devices ****

card 0: mxssgtl5000 [mxs_sgtl5000], device 1: HiFi Capture sgtl5000-1 []

  Subdevices: 1/1

  Subdevice #0: subdevice #0

Please, help!