> > But on platforms where they can enable the WCLK early they shouldn't be > looping around here for anything like 400ms. In an ideal world when that > widget is run SRM should hopefully be already locked but the code does > allow for some delay. Actually, having a long delay also helps show the user > that something isn't right here so I'm somewhat loathed to change this. > > Even if you do reduce the retry timings what you're still not protecting > against is the possibility of audio artefacts when SRM finally locks. You want > this to lock before the any of the audio path is up so I think we need to find a > way to resolve that rather than relying on getting lucky with a smooth power- > up. > Hi Adam, Thanks for the explanation. So the purpose of the code is providing some timing tolerance for SRM to lock? If so, I would suggest adding warning message for the lock fail so people have a clue if their design fails the CTS test. Hard to say if Google further reduces the Cold latency again in the future. Regards, Brent _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
