[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