On Fri, Mar 11, 2016 at 11:25:22AM +0100, Takashi Iwai wrote: > > I guess my return question would be I can imagine many reasons > > why a pointer query might fail, especially for off chip DSPs. > > What is the reasoning for wanting to hide those errors from the > > rest of the system? It seems to me it would be best to handle an > > error as soon as it is noticed, and if a particular system has a > > pointer request that never fails then it can just not return an > > error. > > IMO, propagating the error immediately is a good thing. I guess it > wasn't checked in the pointer callback just because the pointer > callback was supposed to be a simple state copy without involving the > state change. > > OTOH, another question is whether it's enough just to tell the error > there as is. When such an error is detected, it essentially means > that the whole DSP got wrong. What we can do at best is to prepare > for recovery. And this requires the state change. Yes, for recovery on our DSP we do inoke snd_pcm_stop() for all the open streams and then get these restarted. I think we need to do same for compress too.. > Actually, PCM pointer callback may return a special value indicating > an XRUN error. The PCM core reacts for it, stops the stream and > changes the stream state, so that further accesses get the error > consistently. Similar mechanism would be needed for compress API, I > suppose. I didnt know that :) -- ~Vinod _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
