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