USb Host and Isochronous Transfers
I've been trying to get the USB Host software to send audio to a set of Logitech headphones. I have (heavily) modified the Audio V1 Host software to that it will work in this environment, but I finally found the stumbling block that has kept me puzzled for some weeks now.
The problem was that I wanted to send packets to the headphones at 8000SPS (which the headphones can respond to) which meant sending a 8 sample (actually 16 samples as the signal was stereo; 32 bytes as the samples were in PCM) packet every millisecond (again in accordance with the headphones capabilities). However I could not get the sound out of the headphones correctly - rather I got a 1KHz "buzz" regardless of the combination of samples and packet frequencies (I noted that my Windows XP box sent 80 samples every 10 mSec etc).
I finally tracked it down to the following line within the _USB_SetBDT function in the USB_HOST.C file:
if (pCurrentEndpoint->bmAttributes.bfTransferType == USB_TRANSFER_TYPE_ISOCHRONOUS)
// Isochronous transfers are always the same size, though the device may choose to send less.
currentPacketSize = pCurrentEndpoint->wMaxPacketSize;
(This is about line 5105 in the V2010-10-19 library distribution)
As you can see, and is reflected in the comment, the packet size sent to the device is ALWAYS the maximum packet size, regardless of the actual number of bytes in the isochronous packet.
When I changed this to send the maximum packet size in an "IN" request (device to host) where this would make sense to me and to use the actual packet size on an "OUT" request (host to device) then suddenly I get the sound coming through clearly in the headphones.
My question is: "why is this so" (to quote a person who is famous in Australia)? If there any reason why the maximum packet size should be used in an OUT request? If so, how should the packet be constructed to make sure that the device only processes the correct bytes?
Is there something ELSE that need to be done when sending audio isochronous packets as opposed to non-audio isochronous packets?
Alternatively, is this a "bug" that needs to be reported to Microchip?