[alsa-devel] [PATCH v2 3/8] ALSA: aloop: loopback_timer_stop: Support return of error code

Andrew Gabbasov andrew_gabbasov at mentor.com
Wed Nov 6 18:45:51 CET 2019


Thank you very much for your response.

> From: Takashi Iwai <tiwai at suse.de>
> Sent: Wednesday, November 6, 2019 18:51
> 
> On Tue, 05 Nov 2019 15:32:13 +0100,
> Andrew Gabbasov wrote:
> >
> > From: Timo Wischer <twischer at de.adit-jv.com>
> >
> > This is required for additional timer implementations which could detect
> > errors and want to throw them.
> >
> > Signed-off-by: Timo Wischer <twischer at de.adit-jv.com>
> > Signed-off-by: Andrew Gabbasov <andrew_gabbasov at mentor.com>
> 
> 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



More information about the Alsa-devel mailing list