[alsa-devel] [PATCH v4 14/15] ALSA: usb-audio: always wait in start_endpoints
eldad at fogrefinery.com
Tue Oct 8 21:25:17 CEST 2013
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.
More information about the Alsa-devel