On Thu, 14 Feb 2019, Michael [ISO-8859-1] H�el wrote: > Hi, > > With kernel 4.20.8 as well as 5.0-rc6 I have the following problem. > I have an AT2020USBi microphone from audio-technica. This is a full speed USB > device which supports 24 bit audio at up to 96 kHz. Although the hardware is > only mono it requestes a wMaxPacketSize of 576 corresponding to 24 bit stereo > at 96 kHz. According to my understanding this is compliant to the USB 2.0 > specification, because up to 80% of the bandwidth can be used for iso > transfers. However the linux kernel does not grant this bandwidth although it > is the only device connected to one port of a USB 2.0 hub. It reports: > usb 2-1.3: cannot submit urb 0, error -28: not enough bandwidth > > I checked the logic in iso_stream_schedule and sitd_slot_ok from drivers/usb/ > host/ehci-sched.c and found the following. > - The desired packet size fits into 4 uframes. > - The variables are calculated to hs_transfers = 4 and stream->ps.cs_mask = > 0xFC01 (line 1110). > - Searching for a suitable slot starts in iso_stream_schedule. > - Uframe 7 and 6 are not used. "if ((start % 8) >= 6) continue;" line 1530 > - Uframe 5 to 1 are rejected, because the condition "mask & ~0xffff" in line > 1411 ist not met. > - Uframe 0 does not work, because there is alredy some reserved bandwith and > tt_available fails. > > I am not sure about the intended behavior of the code. If I apply the > following change then the transfer is scheduled for uframe 5 to 2 and the > microphone works well. > > diff -up linux-4.20.8/drivers/usb/host/ehci-sched.c linux-4.20.8.new/drivers/ > usb/host/ehci-sched.c > --- linux-4.20.8/drivers/usb/host/ehci-sched.c 2019-01-31 08:15:47.000000000 > +0100 > +++ linux-4.20.8.new/drivers/usb/host/ehci-sched.c 2019-02-13 > 22:05:10.622284415 +0100 > @@ -1408,7 +1408,7 @@ sitd_slot_ok( > return 0; > > /* for IN, don't wrap CSPLIT into the next frame */ > - if (mask & ~0xffff) > + if (mask & ~0x3ffff) > return 0; > > /* check bandwidth */ As you have seen, the support for isochronous scheduling with full-speed devices in ehci-hcd is deficient. Improving it would be extremely difficult; the requirements described in the USB and EHCI specs are very complex. Nobody has implemented siTD back link pointers, FSTN nodes, or periodic-schedule rebalancing in Linux. For the most part, the code tries to follow the spec by restricting the use of packets that would be too large for it to handle. The change you suggest above, for instance, would violate the spec. However now and then this restriction leads to trouble and unfortunately, you are the victim. If you would like to work on improving the driver, I'd be happy to help. Alan Stern
