Disable DAPM for click avoidance ?

Disable DAPM for click avoidance ?

[Ricard Wanderlof]

I'm having an issue with a codec where the normal DAPM procedure of 
disabling most of the codec when there is no stream ongoing results in 
large clicks when a playback stream starts and stops, because the output 
jumps from 0V when the output is disabled to over a volt when the output 
is enabled. 

There appears to be a 'slow stop/start' feature in the codec, however, it 
takes about one second to ramp up and down the output voltage, and that is 
too long a delay when starting a stream.

In our usecase the power consumtion of the codec is negligable 
compared to the rest of the electronics, so leaving the codec running at 
all times is perfectly feasible.

Is there any way from a machine driver to disable the DAPM switching, i.e. 
leave parts of the codec running at all times? In this specific case, 
there are two internal PM controls which enable the output. One of them is 
controlled by an output mixer element (SND_SOC_DAPM_MIXER_E), and the 
other one from set_bias_level().

I've had a look in the core code, but it seems that the whole business of 
changing the bias level when a stream is started is always performed and 
that there is no way to say "Set the bias level to ON and leave it there".

An alternative would be to augment the codec driver with an 'always on' 
feature, which effectively always enables PM for certain parts of the 
chip. But it seems like the wrong place to do this type of thing.

Another use for this feature is that we have had a lot of problems over 
the years with buggy I2S interfaces misbehaving when streams are started 
and stopped, and there would be an advantage to letting the AIF run the 
whole time after startup.

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

Re: Disable DAPM for click avoidance ?

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 1360 bytes --]

On Wed, Nov 22, 2017 at 01:33:37PM +0100, Ricard Wanderlof wrote:

Always CC maintainers on postings if you want them to be reliably
seen...

> I'm having an issue with a codec where the normal DAPM procedure of 
> disabling most of the codec when there is no stream ongoing results in 
> large clicks when a playback stream starts and stops, because the output 
> jumps from 0V when the output is disabled to over a volt when the output 
> is enabled. 

> There appears to be a 'slow stop/start' feature in the codec, however, it 
> takes about one second to ramp up and down the output voltage, and that is 
> too long a delay when starting a stream.

The CODEC driver is broken, it shouldn't be powering off on idle if it
takes a second to ramp, it should be leaving VMID up while the system is
running - this is what the _STANDBY bias level is all about.  Look at
what older CODEC drivers like the wm8731 do.

> Another use for this feature is that we have had a lot of problems over 
> the years with buggy I2S interfaces misbehaving when streams are started 
> and stopped, and there would be an advantage to letting the AIF run the 
> whole time after startup.

This is why we've got the digital_mute() callback - the idea is that the
output is just going to be discarded until the interface has had a
chance to settle down.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Disable DAPM for click avoidance ?

[Ricard Wanderlof]

On Wed, 22 Nov 2017, Mark Brown wrote:

> On Wed, Nov 22, 2017 at 01:33:37PM +0100, Ricard Wanderlof wrote:
> 
> Always CC maintainers on postings if you want them to be reliably
> seen...

Ok. I thought it was more of a general question than a maintainer question 
but I'll keep it in mind in future.

> > I'm having an issue with a codec where the normal DAPM procedure of 
> > disabling most of the codec when there is no stream ongoing results in 
> > large clicks when a playback stream starts and stops, because the output 
> > jumps from 0V when the output is disabled to over a volt when the output 
> > is enabled. 
> 
> > There appears to be a 'slow stop/start' feature in the codec, however, it 
> > takes about one second to ramp up and down the output voltage, and that is 
> > too long a delay when starting a stream.
> 
> The CODEC driver is broken, it shouldn't be powering off on idle if it
> takes a second to ramp, it should be leaving VMID up while the system is
> running - this is what the _STANDBY bias level is all about.  Look at
> what older CODEC drivers like the wm8731 do.

It actually does leave VMID on as soon as the codec is not at the 
_OFF level, the problem is really that the output buffer is not enabled 
until a playback stream is set up, and its not until the output buffer is 
enabled that the output attains its operating level.

Of course, one solution would be to change the driver to enable the output 
already at the _STANDBY level. It does seem to me that that would violate 
part of the whole point of DAPM, on the other hand, I would think that 
at some point power management must take a second seat to actually getting 
a good user experience.

> > Another use for this feature is that we have had a lot of problems over 
> > the years with buggy I2S interfaces misbehaving when streams are started 
> > and stopped, and there would be an advantage to letting the AIF run the 
> > whole time after startup.
> 
> This is why we've got the digital_mute() callback - the idea is that the 
> output is just going to be discarded until the interface has had a 
> chance to settle down.

The problems we've had have been on the CPU side, with I2S interfaces that 
have problems synchronizing to an ongoing I2S stream when the CPU AIF is 
in slave mode, to the extent that in some cases its impossible to 
determine if the first sample received by or sent from the I2S interface 
is the left or right channel. If the DAIs had been set up once and been 
allowed to run continuously even when there is no actual audio to 
transfer, it would have helped this situation. Agreed, I'd rather have a 
DAI that worked properly, but sometimes one doesn't have that luxery. :-(

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

Re: Disable DAPM for click avoidance ?

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 2892 bytes --]

On Thu, Nov 23, 2017 at 10:41:33AM +0100, Ricard Wanderlof wrote:
> On Wed, 22 Nov 2017, Mark Brown wrote:
> > On Wed, Nov 22, 2017 at 01:33:37PM +0100, Ricard Wanderlof wrote:

> > Always CC maintainers on postings if you want them to be reliably
> > seen...

> Ok. I thought it was more of a general question than a maintainer question 
> but I'll keep it in mind in future.

If you don't copy any actual people the chances of getting a response
are vastly reduced.

> > The CODEC driver is broken, it shouldn't be powering off on idle if it
> > takes a second to ramp, it should be leaving VMID up while the system is
> > running - this is what the _STANDBY bias level is all about.  Look at
> > what older CODEC drivers like the wm8731 do.

> It actually does leave VMID on as soon as the codec is not at the 
> _OFF level, the problem is really that the output buffer is not enabled 
> until a playback stream is set up, and its not until the output buffer is 
> enabled that the output attains its operating level.

> Of course, one solution would be to change the driver to enable the output 
> already at the _STANDBY level. It does seem to me that that would violate 
> part of the whole point of DAPM, on the other hand, I would think that 
> at some point power management must take a second seat to actually getting 
> a good user experience.

Yes, you'll need to do something like leave the outputs enabled.  Most
devices have some facility to keep VMID switched to the outputs, though
I did see a few where someone thought it was a good idea to power on
from cold always.  A device that old isn't going to be that competitive
power wise anyway even if it were well implemented which this one seems
to not have been.

> > This is why we've got the digital_mute() callback - the idea is that the 
> > output is just going to be discarded until the interface has had a 
> > chance to settle down.

> The problems we've had have been on the CPU side, with I2S interfaces that 
> have problems synchronizing to an ongoing I2S stream when the CPU AIF is 

That's what the digital mute handling is for - we're just throwing away
any garbage the CPU puts out before it's stable.  We're not expecting it
to work around any CODEC side issues.

> in slave mode, to the extent that in some cases its impossible to 
> determine if the first sample received by or sent from the I2S interface 
> is the left or right channel. If the DAIs had been set up once and been 
> allowed to run continuously even when there is no actual audio to 
> transfer, it would have helped this situation. Agreed, I'd rather have a 
> DAI that worked properly, but sometimes one doesn't have that luxery. :-(

If you're getting L/R swap issues on some startups leaving things
enabled all the time will mean that your random swap issue gets moved to
boot.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Disable DAPM for click avoidance ?

[Ricard Wanderlof]

On Thu, 23 Nov 2017, Mark Brown wrote:

> If you don't copy any actual people the chances of getting a response
> are vastly reduced.

My point has been that I don't want to pester any specific people ... but 
point taken that otherwise it just ends up as an FYI.

> > Of course, one solution would be to change the driver to enable the output 
> > already at the _STANDBY level. It does seem to me that that would violate 
> > part of the whole point of DAPM, on the other hand, I would think that 
> > at some point power management must take a second seat to actually getting 
> > a good user experience.
> 
> Yes, you'll need to do something like leave the outputs enabled.  Most
> devices have some facility to keep VMID switched to the outputs, though
> I did see a few where someone thought it was a good idea to power on
> from cold always.  A device that old isn't going to be that competitive
> power wise anyway even if it were well implemented which this one seems
> to not have been.

In my case the codec is only a couple of years old, so I'd say it 
qualifies as 'modern'. There's a table in the data sheet describing the 
power consumption for various combinations of the PM control bits but 
unfortunately the case of having the outbut buffer enabled but not the DAC 
is not listed. I could always ask the manufacturer directly of course. Or 
simply measure it myself on an evaluation board to get an idea.

> > > This is why we've got the digital_mute() callback - the idea is that the 
> > > output is just going to be discarded until the interface has had a 
> > > chance to settle down.
> 
> > The problems we've had have been on the CPU side, with I2S interfaces that 
> > have problems synchronizing to an ongoing I2S stream when the CPU AIF is 
> 
> That's what the digital mute handling is for - we're just throwing away
> any garbage the CPU puts out before it's stable.  We're not expecting it
> to work around any CODEC side issues.

During which time period is the digital mute enabled? From the first 
stream startup until everything is up and running?
> 
> > in slave mode, to the extent that in some cases its impossible to 
> > determine if the first sample received by or sent from the I2S interface 
> > is the left or right channel. If the DAIs had been set up once and been 
> > allowed to run continuously even when there is no actual audio to 
> > transfer, it would have helped this situation. Agreed, I'd rather have a 
> > DAI that worked properly, but sometimes one doesn't have that luxery. :-(
> 
> If you're getting L/R swap issues on some startups leaving things
> enabled all the time will mean that your random swap issue gets moved to
> boot.

Basically the situation I had was that it worked fine on first startup, it 
was on subsequent startups/shutdowns that the problems occurred, as
shutting down the audio streams seemed to leave the CPU DAI in some 
intermediate state, from which it could only recover if completely reset, 
which did not play well with the concept of for instance having a capture 
stream running continuously while a playback stream was started and 
stopped.

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

Re: Disable DAPM for click avoidance ?

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 1948 bytes --]

On Thu, Nov 23, 2017 at 03:32:26PM +0100, Ricard Wanderlof wrote:
> On Thu, 23 Nov 2017, Mark Brown wrote:

> > Yes, you'll need to do something like leave the outputs enabled.  Most
> > devices have some facility to keep VMID switched to the outputs, though
> > I did see a few where someone thought it was a good idea to power on
> > from cold always.  A device that old isn't going to be that competitive
> > power wise anyway even if it were well implemented which this one seems
> > to not have been.

> In my case the codec is only a couple of years old, so I'd say it 
> qualifies as 'modern'. There's a table in the data sheet describing the 

Wow, people are still designing new VMID based CODECs - what is this one?

> > That's what the digital mute handling is for - we're just throwing away
> > any garbage the CPU puts out before it's stable.  We're not expecting it
> > to work around any CODEC side issues.

> During which time period is the digital mute enabled? From the first 
> stream startup until everything is up and running?

It should be enabled at all times that we're not actively playing
anything.  Though now that I think about it we need to go through and
mute everything during probe otherwise it won't be muted on first power
on.

> > If you're getting L/R swap issues on some startups leaving things
> > enabled all the time will mean that your random swap issue gets moved to
> > boot.

> Basically the situation I had was that it worked fine on first startup, it 
> was on subsequent startups/shutdowns that the problems occurred, as
> shutting down the audio streams seemed to leave the CPU DAI in some 
> intermediate state, from which it could only recover if completely reset, 
> which did not play well with the concept of for instance having a capture 
> stream running continuously while a playback stream was started and 
> stopped.

That's a new (and buggy) one...

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Disable DAPM for click avoidance ?

[Ricard Wanderlof]

On Thu, 23 Nov 2017, Mark Brown wrote:

> > In my case the codec is only a couple of years old, so I'd say it 
> > qualifies as 'modern'. There's a table in the data sheet describing the 
> 
> Wow, people are still designing new VMID based CODECs - what is this one?

In this case it's the AK4637. From the data sheet it looks to be from 
2015.

I know there are codecs that do not need their inputs/outputs (internally) 
biased to a VMID, but have a 0V bias level using an internal charge-pump 
design to generate the required internal negative voltages, if that is 
what you're thinking of. One disadvantage from a cost perspective is the 
external capacitors needed for the charge pump to operate, and the design 
in which this one is used is extermely cost optimized.

> > During which time period is the digital mute enabled? From the first 
> > stream startup until everything is up and running?
> 
> It should be enabled at all times that we're not actively playing
> anything.  

Ok. So it really would be the last callback made (with mute = off) to the 
codec driver once everything else has been set up then?

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

Re: Disable DAPM for click avoidance ?

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 1133 bytes --]

On Fri, Nov 24, 2017 at 10:43:48AM +0100, Ricard Wanderlof wrote:

> I know there are codecs that do not need their inputs/outputs (internally) 
> biased to a VMID, but have a 0V bias level using an internal charge-pump 
> design to generate the required internal negative voltages, if that is 
> what you're thinking of. One disadvantage from a cost perspective is the 
> external capacitors needed for the charge pump to operate, and the design 
> in which this one is used is extermely cost optimized.

Right, but it's not like none of that wasn't already covered by the many
existing CODECs in that space that already paid back their development
costs years ago, it's surprising that anyone would try to make something
new there.

> > > During which time period is the digital mute enabled? From the first 
> > > stream startup until everything is up and running?

> > It should be enabled at all times that we're not actively playing
> > anything.  

> Ok. So it really would be the last callback made (with mute = off) to the 
> codec driver once everything else has been set up then?

That's the idea.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Disable DAPM for click avoidance ?

[Ricard Wanderlof]

Hi Mark,

Picking up an old thread here, I'm working on a VMID based codec with 
associated driver from AKM, where the VMID and audio outputs are only 
switched on when the devices is actually outputting audio data (in the 
playback case), causing loud clicks when a stream is started and stopped.

On Wed, 22 Nov 2017, Mark Brown wrote:

> On Wed, Nov 22, 2017 at 01:33:37PM +0100, Ricard Wanderlof wrote:
> 
> > I'm having an issue with a codec where the normal DAPM procedure of 
> > disabling most of the codec when there is no stream ongoing results in 
> > large clicks when a playback stream starts and stops, because the output 
> > jumps from 0V when the output is disabled to over a volt when the output 
> > is enabled. 
> 
> > There appears to be a 'slow stop/start' feature in the codec, however, it 
> > takes about one second to ramp up and down the output voltage, and that is 
> > too long a delay when starting a stream.
> 
> The CODEC driver is broken, it shouldn't be powering off on idle if it
> takes a second to ramp, it should be leaving VMID up while the system is
> running - this is what the _STANDBY bias level is all about.  Look at
> what older CODEC drivers like the wm8731 do.

I was tracing through what actually is called in the codec driver when a 
stream is started, and from what I can see ALSA sequences through the 
STANDBY, PREPARE and ON states when a stream is started, with no other 
calls to set_bias_level prior to that. So it would seem that the STANDBY 
level is reached during the process of starting the stream, in other 
words, VMID and the outputs would have to be enabled already in the OFF 
state.

In our system, the power consumed by the codec is negligible compared to 
the rest of the system at all times, so it's not a problem to leave 
basically the whole codec up, but I am trying understand what is the 
Right Thing to do here.

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

Re: Disable DAPM for click avoidance ?

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 2441 bytes --]

On Mon, Mar 19, 2018 at 04:53:23PM +0100, Ricard Wanderlof wrote:
> On Wed, 22 Nov 2017, Mark Brown wrote:

> > The CODEC driver is broken, it shouldn't be powering off on idle if it
> > takes a second to ramp, it should be leaving VMID up while the system is
> > running - this is what the _STANDBY bias level is all about.  Look at
> > what older CODEC drivers like the wm8731 do.

> I was tracing through what actually is called in the codec driver when a 
> stream is started, and from what I can see ALSA sequences through the 
> STANDBY, PREPARE and ON states when a stream is started, with no other 
> calls to set_bias_level prior to that. So it would seem that the STANDBY 
> level is reached during the process of starting the stream, in other 
> words, VMID and the outputs would have to be enabled already in the OFF 
> state.

To repeat if you're setting idle_bias_off for a CODEC like this you're
doing it wrong.  The device shouldn't be going to a bias level lower
than _STANDBY while the system is out of suspend.

> In our system, the power consumed by the codec is negligible compared to 
> the rest of the system at all times, so it's not a problem to leave 
> basically the whole codec up, but I am trying understand what is the 
> Right Thing to do here.

Are you sure that the device doesn't have any facility for switching the
outputs to a lower power maintenance state while things are idle?  This
sounds like an extremely basic device, even by the standards of a decade
ago.  The reason for powering down the outputs isn't just a power one,
often especially with these older devices there's an audible noise floor
even when playing silence which is distracting for users in quiet
environments.  Powering down eliminates this noise floor.

The easiest thing to do if you just want to keep playing audio all the
time is to handle this in the sound server and have it keep playing.  If
the hardware really is as limited as it seems there's going to be no
good way to support it.  Without knowing how flexible it is or what
features it has it's difficult to be specific about the best way to
handle it but whatever gets done having a stream coming from the CPU all
the time will work.  The more control there is the more likely it is
that the driver is going to have to power it down on idle anyway to
allow configuration changes to be made without generating pops and
clicks.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Disable DAPM for click avoidance ?

[Ricard Wanderlof]

On Wed, 21 Mar 2018, Mark Brown wrote:

> > > The CODEC driver is broken, it shouldn't be powering off on idle if it
> > > takes a second to ramp, it should be leaving VMID up while the system is
> > > running - this is what the _STANDBY bias level is all about.  Look at
> > > what older CODEC drivers like the wm8731 do.
> 
> > I was tracing through what actually is called in the codec driver when a 
> > stream is started, and from what I can see ALSA sequences through the 
> > STANDBY, PREPARE and ON states when a stream is started, with no other 
> > calls to set_bias_level prior to that. So it would seem that the STANDBY 
> > level is reached during the process of starting the stream, in other 
> > words, VMID and the outputs would have to be enabled already in the OFF 
> > state.
> 
> To repeat if you're setting idle_bias_off for a CODEC like this you're
> doing it wrong.  The device shouldn't be going to a bias level lower
> than _STANDBY while the system is out of suspend.

Thanks for the pointer, we've gotten the driver from the codec 
manufacturer so I haven't been very familiar with it, and I wasn't even 
aware this configuration option existed. The driver does indeed set 
idle_bias_off, and clearing this bit was the first step to getting it to 
work. I'll spare you the gory details.

My biggest issue here has really been understanding how ALSA expects the 
device to behave, and which options there are. Once I've got that clear 
getting the codec to behave correspondingly is mostly a question of 
reading the data sheet and writing code.

> Are you sure that the device doesn't have any facility for switching the
> outputs to a lower power maintenance state while things are idle?  This
> sounds like an extremely basic device, even by the standards of a decade
> ago.  The reason for powering down the outputs isn't just a power one,
> often especially with these older devices there's an audible noise floor
> even when playing silence which is distracting for users in quiet
> environments.  Powering down eliminates this noise floor.

Yes, there is a bit for setting the output amplifier in power save mode, 
which is handled as a PM bit in the driver. The specs aren't that bad, the 
worst case SNR is 80 dB, with 97 dB typical. The good thing about using 
this bit is that when the output amplifier is in power save mode, there is 
actually a high impedance connection to VMID, so that as long as the 
device is powered on properly, the outputs take a while to reach VMID 
depending on the value of the DC blocking cap on the output, and the slow 
ramp also avoids clicks when powering on the device (and we don't start an 
output stream until quite a while after powering on the system).

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

Re: Disable DAPM for click avoidance ?

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 1026 bytes --]

On Fri, Mar 23, 2018 at 05:23:23PM +0100, Ricard Wanderlof wrote:

> Yes, there is a bit for setting the output amplifier in power save mode, 
> which is handled as a PM bit in the driver. The specs aren't that bad, the 
> worst case SNR is 80 dB, with 97 dB typical. The good thing about using 
> this bit is that when the output amplifier is in power save mode, there is 
> actually a high impedance connection to VMID, so that as long as the 
> device is powered on properly, the outputs take a while to reach VMID 
> depending on the value of the DC blocking cap on the output, and the slow 
> ramp also avoids clicks when powering on the device (and we don't start an 
> output stream until quite a while after powering on the system).

That feature sounds normal for such old devices, you should be using
that rather than ramping VMID from ground every time you want to start
and stop playback.  There's a number of very old drivers doing something
similar, grepping around will probably show something.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]