On Thu, 2 Apr 2015, Peter Chen wrote: > 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? The host controller driver takes _both_ the frame rate (bInterval) and wMaxPacketSize into account. The problem is that with normal audio parameters (for example, 16-bit stereo at 48 KHz) the audio driver will use packets that are much shorter than wMaxPacketSize (192 bytes, not 1023 bytes). But the HCD doesn't know this, and it has to allocate bandwidth under the assumption that all the packets will be as large as possible. That's why real audio devices tend to have lots of alternate settings; each altsetting has a different wMaxPacketSize suitable for a particular set of audio parameters. In the past, people have discussed adding an API for drivers to tell the HCD what size packets they intend to use. This could override the wMaxPacketSize value in the bandwidth calculations. But it was not a high priority, and nobody has implemented it. Alan Stern -- 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
