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

From: Andrew Gabbasov <andrew_gabbasov@mentor.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: Timo Wischer <twischer@de.adit-jv.com>,
	alsa-devel@alsa-project.org, Takashi Iwai <tiwai@suse.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [alsa-devel] [PATCH v2 3/8] ALSA: aloop: loopback_timer_stop: Support return of error code
Date: Wed, 6 Nov 2019 20:45:51 +0300	[thread overview]
Message-ID: <000001d594ca$1dd487f0$597d97d0$@mentor.com> (raw)
In-Reply-To: <s5h36f13sv5.wl-tiwai@suse.de>

Thank you very much for your response.

> From: Takashi Iwai <tiwai@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@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@de.adit-jv.com>
> > Signed-off-by: Andrew Gabbasov <andrew_gabbasov@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

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel