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