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...