Hello Ravi, On 3.3.2014 10:10, B, Ravi wrote:
You are true, long packets was probably cause for babble. I don't have any low level USB analyzer except of usbmon module, where i find, that sound driver sends URBs for bulk transfers with 4K data payload. If i got that correctly, normally it shouldn't matter as it is splitted by host controller module to shorter packets. If i tried to change definition at sound driver for URBs with 512b payload, it doesn't initiate babble event. So it looks like, according to what you wrote, musb host controller module splits that to 1K packets (according to non-standard maxpacket value from endpoint descriptor), which will cause babble. Maybe it is worth of including some ceiling for maxpacket length to avoid that behavior with devices with reported non-standard length.. I googled for that warning and it seems to be few other devices has same problem like HiFace sound card.After connection to Beaglebone it seems to be correctly enumerated (albeit with one warning about its reported standard violating maxpacket length, but itProbably this would be cause for babble? Did you observed bus traces, whether 1024 bytes seen or any break in the packet.
Babble didn't occur immediately after first bulk packet (later some overflow?) according to usbmon capture, where is: device setup, start of playback, few finished URBs.. bus restart after babble (your workaround patch) and again. I've attached three captures - musb with babble, Intel ehci for comparison and finally musb with altered sound driver.
Best regards, Michal
Attachment:
hiface-one-bbb-512k.pcap.gz
Description: application/gzip
Attachment:
hiface-one-bbb-babble.pcap.gz
Description: application/gzip
Attachment:
hiface-one-intel.pcap.gz
Description: application/gzip
