Thank you very much for your response. > From: Takashi Iwai <tiwai@xxxxxxx> > Sent: Wednesday, November 6, 2019 18:51 > > On Tue, 05 Nov 2019 15:32:13 +0100, > Andrew Gabbasov wrote: > > > > From: Timo Wischer <twischer@xxxxxxxxxxxxxx> > > > > This is required for additional timer implementations which could detect > > errors and want to throw them. > > > > Signed-off-by: Timo Wischer <twischer@xxxxxxxxxxxxxx> > > Signed-off-by: Andrew Gabbasov <andrew_gabbasov@xxxxxxxxxx> > > I'd fold this into the patch 2. Both patches do fairly same things > but just for start and stop. OK, I agree. I'll squash these 2 commits into a single one in the next update (there will be an update for sure to fix the snd_cards reference in patch #7). > > And the same question as patch#2 is applied to this one, too, BTW. As for the notifications in case of timer operation failures: For stop/suspend operations, the return code of the timer operation, and of the PCM trigger function as a whole, actually makes no difference, the streams state is changed anyway, so the notification should be done in any case. For start/resume operations, it seems OK to send notifications even if the timer operation fails, if the cable->running and cable->pause fields are set before that (as is now), so that the notified control reflects the changed state. In case of failure the whole operation will be un-done by upper PCM layer, changing the state back, and sending one more notifcation. Alternatively, we could re-order the code and do not set the running fields if timer operation fails (and do not notify in this case). But the undoing stop operation will be executed in this case that will cause the (unpaired) notification, which is probably not quite correct. Thanks. Best regards, Andrew _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
