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