SGTL5000 CODEC line-in noise on i.MX28

cancel
Showing results for 
Search instead for 
Did you mean: 

SGTL5000 CODEC line-in noise on i.MX28

Jump to solution
4,445 Views
CraigMcQueen
Contributor III

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?

Labels (3)
Tags (2)
1 Solution
680 Views
PeterChan
NXP Employee
NXP Employee

Hello Craig,

Could you please try this patch? It reset the SAIF1 to get rid of the recording noise.

View solution in original post

0 Kudos
34 Replies
205 Views
fabio_estevam
NXP Employee
NXP Employee

Hi Aida,

From your description, it looks like the LINE_IN option is not selected in alsamixer.

Please run alsamixer and make sure that LINE_IN is selected for the capture.

Regards,

Fabio Estevam

0 Kudos
205 Views
aidamynzhasova
Contributor II

Fabio,

thanks for reply. I've tried to change "Capture Mux" to LINE_IN, but in this case I don't hear even noise, just silence.

0 Kudos
205 Views
fabio_estevam
NXP Employee
NXP Employee

Aida,

When selecting LINE_IN, please make sure you are connecting a stereo audio source to the LINE_IN jack.

I usually connect my notebook analog output to the mx28evk LINE_IN jack.

Double check the volume level you are applying as well.

I don't have my mx28evk at the moment to try, but linux-next with arecord/aplay a few weeks ago and it was working.

Regards,

Fabio Estevam

205 Views
aidamynzhasova
Contributor II

Fabio,

I tried line input and it works. Thanks very much for your help!

0 Kudos
205 Views
PeterChan
NXP Employee
NXP Employee

Hi Thomas,

We are sorry for the audio noise issue. Jack and I are sharing the same information and we are now working on this.

Regards,

Peter

0 Kudos
205 Views
fabio_estevam
NXP Employee
NXP Employee

Can you test a 3.9 kernel and let us know if the issue is also there?

0 Kudos
205 Views
CraigMcQueen
Contributor III

Fabio Estevam wrote:

Can you test a 3.9 kernel and let us know if the issue is also there?

Hmm, maybe. We're using Timesys for builds, and Timesys is currently supporting 2.6.35 without the latest Freescale patches (I added the Freescale patches myself).

But if there's a 3.9 kernel repository that supports the i.MX28 EVK, I could perhaps try that.

0 Kudos
681 Views
PeterChan
NXP Employee
NXP Employee

Hello Craig,

Could you please try this patch? It reset the SAIF1 to get rid of the recording noise.

View solution in original post

0 Kudos
205 Views
CraigMcQueen
Contributor III

Thanks very much for providing this patch. This is a big help. Initial results indicate this patch did seem to help, but not fix it entirely.

I have done about 10 power cycles. On none of those did I get noisy input. However, twice when I've closed and re-opened the audio device, I've got noisy input. Then on those two occasions, when I've closed and re-opened the audio device again, the noise disappeared.

This is an improvement on previous behaviour, where the noise persisted even if I closed and re-opened the audio device.

So is this a SAIF driver issue, rather than a SGTL5000 driver issue? And why do you think I would still be getting noise sometimes?

0 Kudos
205 Views
PeterChan
NXP Employee
NXP Employee

Could you please tell me how did you close and re-open the audio device so that I can reproduce the noise issue?

The system clock of SGTL5000 comes from the SAIF0_MCLK. If SAIF0 is reset, theSAIF0_MCLK is interrupted and you may need to re-initialize the SGTL5000 again.

0 Kudos
205 Views
CraigMcQueen
Contributor III

PeterChan wrote:

Could you please tell me how did you close and re-open the audio device so that I can reproduce the noise issue?

I am using a C program that does bi-directional audio streaming using libmediastreamer. It's doing 8 kHz audio in both directions.

PeterChan wrote:

The system clock of SGTL5000 comes from the SAIF0_MCLK. If SAIF0 is reset, theSAIF0_MCLK is interrupted and you may need to re-initialize the SGTL5000 again.

I hope this sort of detail is all taken care of by the Linux SGTL5000 audio driver.

0 Kudos
205 Views
PeterChan
NXP Employee
NXP Employee

Yes, the linux SGTL5000 and SAIF audio driver should take care of all the detail about the link.

I tested the audio stream open/close by running this command repeatedly but not yet able to hear noise.

"arecord -t wav -c 2 -r 44100 -f S16_LE -d 3 | aplay"

You may need to hack into linux/sound/soc/mxs/mxs-dai.c to find out if  SAIF0 has been reset in between close and re-open the audio device.

205 Views
CraigMcQueen
Contributor III

I have been testing this further. The noise cases are uncommon, and I have been unable to isolate the problem so far.

I also tested open/close using ecasignalview from ecasound, to loop-back audio input to output and also show the signal level:

ecasignalview -b:256 -f:,,8000 alsahw alsahw

By that method, I was also unable to reproduce the noise issue in multiple tests.

I also ran my code (that uses libmediastreamer) in isolation, and could not reproduce the noise issue in multiple tests.

Now I have two possible theories about interaction with other elements of the system:

1) It is also displaying information on a display on the I2C bus. Could I2C bus activity disturb normal SGTL5000 CODEC initialisation?

2) It is communicating through a radio module. Maybe power load on the system when the radio module begins communications (at about the same time the audio devices are opened) is glitching the power rails.

(2) doesn't seem likely. But (1) may be an issue. We've had issues with audio previously, when the I2C bus was (I think) trying to talk to an I2C device that wasn't communicating. See: Re: sgtl5000 problem on i.mx28. Could these be related?

0 Kudos
205 Views
CraigMcQueen
Contributor III

Now I have two possible theories about interaction with other elements of the system:

1) It is also displaying information on a display on the I2C bus. Could I2C bus activity disturb normal SGTL5000 CODEC initialisation?

2) It is communicating through a radio module. Maybe power load on the system when the radio module begins communications (at about the same time the audio devices are opened) is glitching the power rails.

(2) doesn't seem likely. But (1) may be an issue. We've had issues with audio previously, when the I2C bus was (I think) trying to talk to an I2C device that wasn't communicating. See: Re: sgtl5000 problem on i.mx28. Could these be related?

I tested (1), by doing audio tests while a test program was writing lots of data on the I2C bus. I did 30 audio tests, and had no noise issues. So I think this rules out the I2C bus hypothesis.

Since applying the patch supplied by Peter Chan, I've only had the 2 instances of noise, and never since then. I've probably done 80 or so tests, without noise.

0 Kudos