[alsa-devel] [PATCH v4 14/15] ALSA: usb-audio: always wait in start_endpoints

[Eldad Zack]

On Tue, 8 Oct 2013, Takashi Iwai wrote:

> At Mon, 7 Oct 2013 21:26:57 +0200 (CEST),
> Eldad Zack wrote:
> > 
> > 
> > 
> > On Mon, 7 Oct 2013, Takashi Iwai wrote:
> > 
> > > At Sun,  6 Oct 2013 22:31:19 +0200,
> > > Eldad Zack wrote:
> > > > 
> > > > Start the endpoints at prepare also for capture endpoints,
> > > > since it might be needed to wait for the URBs to be unlinked.
> > > > 
> > > > If an implicit feedback source endpoint stops being used by its
> > > > sink endpoint, but immediately used as a data endpoint, usb_submit_urb
> > > > will return -EBUSY.
> > > > 
> > > > Merge two trigger cases since they are now the same.
> > > This change worries me about the timing.  This change means that the
> > > capture stream isn't started at the moment the trigger callback is
> > > called but at the next urb handling.  It means a possible regression
> > > in the case of realtime usage.
> > 
> > I'm not sure I understand. Do you mean it might cause the delay between 
> > capture and playback to vary at each startup?
> 
> No, I mean that the actual begin of the recording will be delayed in
> comparison with the driver without your patch.  The delay can't be
> avoided in this style.

Ah. I see what you mean.

> > > Is there any reason to do this except for clean up?  IOW, does this
> > > fix any problem by itself?
> > 
> > Yes, I only became aware of it since I bumped into it with my test tool.
> > Attached here - I hope the mailing list accepts attachments.
> 
> I understand that this will be required for the implicit feedback
> case.  But why applying this to *all* other cases, too, although we
> know that this may regress slightly with respect to the latency?
> This is my biggest concern.

Yes, I understand now. I'll of course change that along with all the 
rest and post a new set.
Thanks!

Cheers,
Eldad