On Mon, Mar 30, 2015 at 10:07:35AM -0400, Alan Stern wrote: > On Mon, 30 Mar 2015, Johannes Stezenbach wrote: > > > a USB soundcard in fullspeed mode works correctly > > when directly connected to a musb OTG port in host mode > > on an AM335x SoC, but produces garbled audio output > > when connected via a hub. usbmon shows that in both > > This is a high-speed (USB-2) hub, right? yes > > cases URBs with typically 5 isoc frames of 192 bytes > > length are queued. The wMaxPacketSize of the > > endpoint is 196 bytes. A USB analyzer connected > > via musb and hub revealed that musb breaks > > the 192 byte frames into two parts, one 188 byte > > and one 4 byte frame, ie. a 192 byte OUT transaction > > produces the following token sequence: > > > > SPLIT > > OUT > > DATA0 188 bytes > > SPLIT > > OUT > > DATA0 4 bytes > > That is correct behavior when a full-speed device is connected to a > high-speed hub. Is it? I would expect a single 192 byte packet here, breaking it in two doesn't make sense even if the hub would be able to reassemble the parts. My recollection of the SPLIT mechanism is to free up the HS bus between FS send and FS ACK for other transactions on other hub ports, not to split the data packets. > Have you tried hooking your USB analyzer between the > hub and the sound card? In that position it ought to show a single > 192-byte OUT packet, as you expect. I'll don't have the logs here but I'll let you know asap. IIRC there were CRC errors, but I did not take this log myself, I only took the log between musb host and hub to confirm the data packet split which I assumed was the root cause of the issue. > > The test was done using a 3.18.4 kernel. I reviewed > > the relevant code in musb_core.c, musb_host.c and > > musb_cppi41.c, and added a few debug prints, but > > did not find anything wrong. Since the SPLIT transaction > > is handled by hardware, I'm currently thinking this might > > be a hardware issue. > > Do you have any ideas? Any possible workaround in case > > it is a hardware issue? > > Perhaps the values in the DATA packets are wrong. The best way for you > to tell is to move the bus analyzer downstream from the hub and then > compare the values you see in the packets with the audio data being > played. The ALSA driver should be unaware of the hub and send the same data, right? Thanks, Johannes -- 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
