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