[alsa-devel] [PATCH v4 07/15] ALSA: usb-audio: correct ep use_count semantics (add set_param flag)
Eldad Zack
eldad at fogrefinery.com
Mon Oct 7 21:31:35 CEST 2013
On Mon, 7 Oct 2013, Takashi Iwai wrote:
> At Sun, 6 Oct 2013 22:31:12 +0200,
> Eldad Zack wrote:
> >
> > Currently, use_count is used in snd_usb_endpoint_set_params to
> > ensure the parameters don't get changed for an in-use endpoint.
> >
> > However, there is a subtle condition where this check fails -
> > if hw_params is called on both substreams before calling prepare (for
> > playback) or start trigger (for capture): the endpoint is not yet
> > started, i.e., snd_usb_endpoint_start() does not yet increment use_count.
> >
> > This adds a flag to check if the parameters are set, but does not
> > omit checking the use_count.
> >
> > Signed-off-by: Eldad Zack <eldad at fogrefinery.com>
> >
> > ---
> > v2: Cleaned up the patch, now it does only one thing (add the flag
> > and the check).
>
> I guess this logic doesn't work if a capture stream is re-prepared
> before started. I know that you'll change the capture stream starting
> in the later patch, but then this patch must be applied after that,
> because it implicitly assumes the scheme.
Yes and it causes a regression too, it prevents full-duplex usage
(with jack or client that use the same sequence). Sorry, I forgot to add
that to the commit message.
I left this so the change is clear, I figured it helps when reading the
history.
Should I combine this with the later patch? Or should I put a notice in
this commit message that "this patch breaks... will be fixed later
by..."?
BTW - sorry if that's a trivial question - is it possible for ops to
race, or do the ops get serialized?
If it is possible, I believe there's a few places that need locking.
Cheers,
Eldad
More information about the Alsa-devel
mailing list