Pop and offsets at start of audio playback/record for SGTL5000 on i.MX28

Pop and offsets at start of audio playback/record for SGTL5000 on i.MX28

[Craig McQueen]

I'm testing the 3.14.19 kernel for i.MX28 EVK, which has an SGTL5000 
CODEC. I've also tested on the 3.18-rc4 kernel and confirmed this issue 
still occurs.


Playback

When doing audio playback, I notice that the audio "fades in" over the 
first (approximately) 500 ms of playback. This is very noticeable and 
not ideal in certain applications (e.g. audio notifications that are of 
short duration).

However, if audio playback starts while audio recording is already 
in-progress, then there is no fade-in; instead there is a loud pop. I 
assume the fade-in is there to mask the pop. The pop is very unpleasant 
through headphones. (However, if I do audio playback a _second_ time 
while audio recording is still in-progress, then there is no loud pop 
the second time.)

I didn't think either the pop or the fade-in occurred on the 2.6.35 
kernel. How feasible is it to improve the driver to avoid or reduce the 
pop, and remove the necessity for a fade-in?


Record

When recording, I notice there is a low-frequency ramping offset at the 
start of a recording (after the 400-500 ms of previous audio) of approx 
600-700 ms duration. This also reduces the audio quality at the start of 
the recording. It could reduce the quality of captured audio depending 
on the application usage. I am getting distortion (clipping I assume) of 
my audio input during this time. It could cause a pop on playback (local 
playback or e.g. VoIP transmission to a remote device). It could reduce 
the audio quality through an audio CODEC.

How feasible is it to improve the driver to avoid a ramping offset at 
the start of recording?

-- 
Craig McQueen

Re: Pop and offsets at start of audio playback/record for SGTL5000 on i.MX28

[Michael Trimarchi]

Hi

Il 14/nov/2014 09:44 "Craig McQueen" <craig.mcqueen@beamcommunications.com>
ha scritto:
>
> I'm testing the 3.14.19 kernel for i.MX28 EVK, which has an SGTL5000
CODEC. I've also tested on the 3.18-rc4 kernel and confirmed this issue
still occurs.
>

Are you using it in master or slave mode?

Michael

>
> Playback
>
> When doing audio playback, I notice that the audio "fades in" over the
first (approximately) 500 ms of playback. This is very noticeable and not
ideal in certain applications (e.g. audio notifications that are of short
duration).
>
> However, if audio playback starts while audio recording is already
in-progress, then there is no fade-in; instead there is a loud pop. I
assume the fade-in is there to mask the pop. The pop is very unpleasant
through headphones. (However, if I do audio playback a _second_ time while
audio recording is still in-progress, then there is no loud pop the second
time.)
>
> I didn't think either the pop or the fade-in occurred on the 2.6.35
kernel. How feasible is it to improve the driver to avoid or reduce the
pop, and remove the necessity for a fade-in?
>
>
> Record
>
> When recording, I notice there is a low-frequency ramping offset at the
start of a recording (after the 400-500 ms of previous audio) of approx
600-700 ms duration. This also reduces the audio quality at the start of
the recording. It could reduce the quality of captured audio depending on
the application usage. I am getting distortion (clipping I assume) of my
audio input during this time. It could cause a pop on playback (local
playback or e.g. VoIP transmission to a remote device). It could reduce the
audio quality through an audio CODEC.
>
> How feasible is it to improve the driver to avoid a ramping offset at the
start of recording?
>
> --
> Craig McQueen
>
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Pop and offsets at start of audio playback/record for SGTL5000 on i.MX28

[Craig McQueen]

On 14/11/14 12:45, Michael Trimarchi wrote:
>
> Hi
>
> Il 14/nov/2014 09:44 "Craig McQueen" 
> <craig.mcqueen@beamcommunications.com 
> <mailto:craig.mcqueen@beamcommunications.com>> ha scritto:
> >
> > I'm testing the 3.14.19 kernel for i.MX28 EVK, which has an SGTL5000 
> CODEC. I've also tested on the 3.18-rc4 kernel and confirmed this 
> issue still occurs.
> >
>
> Are you using it in master or slave mode?
>

For the i.MX28 EVK, the SGTL5000 is in slave mode.

-- 
Craig McQueen

Re: Pop and offsets at start of audio playback/record for SGTL5000 on i.MX28

[Michael Trimarchi]

Hi

Il 14/nov/2014 09:58 "Craig McQueen" <craig.mcqueen@beamcommunications.com>
ha scritto:
>
> On 14/11/14 12:45, Michael Trimarchi wrote:
>>
>> Hi
>>
>> Il 14/nov/2014 09:44 "Craig McQueen" <
craig.mcqueen@beamcommunications.com> ha scritto:
>> >
>> > I'm testing the 3.14.19 kernel for i.MX28 EVK, which has an SGTL5000
CODEC. I've also tested on the 3.18-rc4 kernel and confirmed this issue
still occurs.
>> >
>>
>> Are you using it in master or slave mode?
>
>

Try to change the pin mux of data line in order to be hz in idle mode and
add a small pull down resistor. Can you check if the dataline is up when
clocks go off?

Michael

> For the i.MX28 EVK, the SGTL5000 is in slave mode.
>
> --
> Craig McQueen
>

Re: Pop and offsets at start of audio playback/record for SGTL5000 on i.MX28

[Craig McQueen]

On 14/11/14 13:04, Michael Trimarchi wrote:
>
> Hi
>
> Il 14/nov/2014 09:58 "Craig McQueen" 
> <craig.mcqueen@beamcommunications.com 
> <mailto:craig.mcqueen@beamcommunications.com>> ha scritto:
> >
> > On 14/11/14 12:45, Michael Trimarchi wrote:
> >>
> >> Hi
> >>
> >> Il 14/nov/2014 09:44 "Craig McQueen" 
> <craig.mcqueen@beamcommunications.com 
> <mailto:craig.mcqueen@beamcommunications.com>> ha scritto:
> >> >
> >> > I'm testing the 3.14.19 kernel for i.MX28 EVK, which has an 
> SGTL5000 CODEC. I've also tested on the 3.18-rc4 kernel and confirmed 
> this issue still occurs.
> >> >
> >>
> >> Are you using it in master or slave mode?
> >
> >
>
> Try to change the pin mux of data line in order to be hz in idle mode 
> and add a small pull down resistor. Can you check if the dataline is 
> up when clocks go off?
>

Is it the I2S_DIN pin you're referring to?

This is the Freescale i.MX28 EVK we're talking about, so it's best to 
have a software fix that works on the stock EVK hardware. I'm checking 
the schematics and I don't see a pull-down. The following is in the 
imx28.dtsi device tree source:

                 saif0_pins_b: saif0@1 {
                     reg = <1>;
                     fsl,pinmux-ids = <
                         MX28_PAD_SAIF0_LRCLK__SAIF0_LRCLK
                         MX28_PAD_SAIF0_BITCLK__SAIF0_BITCLK
                         MX28_PAD_SAIF0_SDATA0__SAIF0_SDATA0
                     >;
                     fsl,drive-strength = <MXS_DRIVE_12mA>;
                     fsl,voltage = <MXS_VOLTAGE_HIGH>;
                     fsl,pull-up = <MXS_PULL_ENABLE>;
                 };

However on the i.MX28 I don't think the SAIF0_SDATA0 pin actually has a 
pull-up (only a few pins do).

Anyway, I will look into that soon.

-- 
Craig McQueen

Re: Pop and offsets at start of audio playback/record for SGTL5000 on i.MX28

[Michael Trimarchi]

Hi

Il 17/nov/2014 08:35 "Craig McQueen" <craig.mcqueen@beamcommunications.com>
ha scritto:
>
> On 14/11/14 13:04, Michael Trimarchi wrote:
>>
>> Hi
>>
>> Il 14/nov/2014 09:58 "Craig McQueen" <
craig.mcqueen@beamcommunications.com> ha scritto:
>> >
>> > On 14/11/14 12:45, Michael Trimarchi wrote:
>> >>
>> >> Hi
>> >>
>> >> Il 14/nov/2014 09:44 "Craig McQueen" <
craig.mcqueen@beamcommunications.com> ha scritto:
>> >> >
>> >> > I'm testing the 3.14.19 kernel for i.MX28 EVK, which has an
SGTL5000 CODEC. I've also tested on the 3.18-rc4 kernel and confirmed this
issue still occurs.
>> >> >
>> >>
>> >> Are you using it in master or slave mode?
>> >
>> >
>>
>> Try to change the pin mux of data line in order to be hz in idle mode
and add a small pull down resistor. Can you check if the dataline is up
when clocks go off?
>
>
> Is it the I2S_DIN pin you're referring to?
>
> This is the Freescale i.MX28 EVK we're talking about, so it's best to
have a software fix that works on the stock EVK hardware. I'm checking the
schematics and I don't see a pull-down. The following is in the imx28.dtsi
device tree source:
>
>                 saif0_pins_b: saif0@1 {
>                     reg = <1>;
>                     fsl,pinmux-ids = <
>                         MX28_PAD_SAIF0_LRCLK__SAIF0_LRCLK
>                         MX28_PAD_SAIF0_BITCLK__SAIF0_BITCLK
>                         MX28_PAD_SAIF0_SDATA0__SAIF0_SDATA0
>                     >;
>                     fsl,drive-strength = <MXS_DRIVE_12mA>;
>                     fsl,voltage = <MXS_VOLTAGE_HIGH>;
>                     fsl,pull-up = <MXS_PULL_ENABLE>;
>                 };
>
> However on the i.MX28 I don't think the SAIF0_SDATA0 pin actually has a
pull-up (only a few pins do).
>
> Anyway, I will look into that soon.
>

I think that some patch was submitted for this pop last week

Michael

> --
> Craig McQueen
>

Re: Pop and offsets at start of audio playback/record for SGTL5000 on i.MX28

[Fabio Estevam]

On Thu, Nov 13, 2014 at 11:43 PM, Craig McQueen
<craig.mcqueen@beamcommunications.com> wrote:
> I'm testing the 3.14.19 kernel for i.MX28 EVK, which has an SGTL5000 CODEC.
> I've also tested on the 3.18-rc4 kernel and confirmed this issue still
> occurs.
>
>
> Playback
>
> When doing audio playback, I notice that the audio "fades in" over the first
> (approximately) 500 ms of playback. This is very noticeable and not ideal in
> certain applications (e.g. audio notifications that are of short duration).

It seems that this behaviour can be controlled by the SMALL_POP bit:
"Setting this bit slows down the VAG ramp from ~200ms to ~400ms to
reduce the startup
pop, but increases the turn on/off time."

Looking at the code I see its definition is wrong:

--- a/sound/soc/codecs/sgtl5000.c
+++ b/sound/soc/codecs/sgtl5000.c
@@ -1307,8 +1307,7 @@ static int sgtl5000_probe(struct snd_soc_codec *codec)

        /* enable small pop, introduce 400ms delay in turning off */
        snd_soc_update_bits(codec, SGTL5000_CHIP_REF_CTRL,
-                               SGTL5000_SMALL_POP,
-                               SGTL5000_SMALL_POP);
+                               SGTL5000_SMALL_POP, 1);

        /* disable short cut detector */
        snd_soc_write(codec, SGTL5000_CHIP_SHORT_CTRL, 0);
diff --git a/sound/soc/codecs/sgtl5000.h b/sound/soc/codecs/sgtl5000.h
index 2f8c889..bd7a344 100644
--- a/sound/soc/codecs/sgtl5000.h
+++ b/sound/soc/codecs/sgtl5000.h
@@ -275,7 +275,7 @@
 #define SGTL5000_BIAS_CTRL_MASK                        0x000e
 #define SGTL5000_BIAS_CTRL_SHIFT               1
 #define SGTL5000_BIAS_CTRL_WIDTH               3
-#define SGTL5000_SMALL_POP                     0x0001
+#define SGTL5000_SMALL_POP                     0

This change keeps the original intention of enabling 'small pop'. You
can try 'SGTL5000_SMALL_POP, 0);' to see if you get a quicker
response.