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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
