On Wed, Apr 01, 2015 at 10:35:16AM -0400, Alan Stern wrote: > On Wed, 1 Apr 2015, Peter Chen wrote: > > > > This is bad. All the endpoints have maxpacket = 1023, and that's much > > > too big for this test. We need a maxpacket size of 64 (maybe a little > > > bigger but not much). > > > > > > > Back to this issue, 1024 bytes is only ~70% for frame, why it reports > > "iso sched full" when I only wants to use one endpoint for playback > > or capture? > > The low/full-speed periodic scheduler in ehci-hcd is pretty bad. It > doesn't follow the recommendations of the USB spec and it is > sub-optimal in several respects. One consequence of these problems is > that it is not able to schedule any isochronous transfer with a maximum > packet size larger than about 990 bytes. > Get it. That's why I got "iso sched full" with direct full-speed connection between UAC2 gadget (with wMaxPacketSize = 1023) and host controller. But why it does not allocate bandwidth according to frame rate, but according to wMaxPacketSize? Audio does requirement (through URB) for it? > Your case is even worse, because with a full-speed hub plugged in, part > of the periodic schedule is already committed for the hub's status URB. > As a result, no isochronous transfer with maxpacket larger than about > 830 bytes can be scheduled. > > Alan Stern > -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
