Digital mute being automatically set for SGTL5000 with no user input

[ralph__]

I'm investigating a problem with the SGTL5000 on our custom board. We are using Pulseaudio and find that if the LINE-IN of the SGTL5000 is not connected to an external earth, it will automatically enable its digital mute *on the LINE-OUT*. It is totally unclear how this happens as I am monitoring the I2C bus transactions and the last time the digital mute is unset we find it is immediately read back as correctly unset. (Digital mute == DAC_MUTE_LEFT and DAC_MUTE_RIGHT)

When we find the digital mute to be self-setting, we also see the VOL_BUSY_DAC_LEFT/VOL_BUSY_DAC_RIGHT bits to be staying high and never going low.

Has anyone else come across this or can suggest why these bits are automatically being set? It doesn't make a lot of sense that the audio input must be grounded for the audio output not to be self-muted.

Thanks,
Ralph

[AugustoRGomez]

Hi Ralph.

I know this post has years inactive, but I'm dealing with the same problem in a project under delevolpment, I've tried to route MIC -> ADC -> DAC -> HP out, i get no sound, only pop/clicking at the begeninng, bits VOL_BUSY_DAC_LEFT/VOL_BUSY_DAC_RIGHT are high state too, could you please tell how did you solve it? 

[art]

There is no any auto mute function in the SGTL5000 codec. The most likely cause

of the issue is some wrong initialization or control sequence. Please exactly

follow the initialization and control procedures, described in the AN3663 App

Note that you can find on the SGTL5000 Documentation web page:

http://www.freescale.com/products/analog-power-management/interface/ultra-low-power-audio-codec:SGTL...

Have a great day,
Artur

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[ralph__]

Thanks, I had no idea about that document. I'm actually using the kernel driver although I've already had to fix one bug so maybe there's another.