At Mon, 7 Oct 2013 21:31:35 +0200 (CEST), Eldad Zack wrote:
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@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..."?
At best shuffle the order of patches so that this one is applied after the required patches.
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.
Which ops specifically? For a PCM substream, it's serialized. For duplex substreams, both can be called at the same time, thus you'd need to protect concurrent accesses, if any.
Takashi