USB Audio Class 2 has 2 Configurations with the same Index
Posted: Thu Dec 01, 2016 4:16 am
First of all, I'm working with a couple of different xCORE 200 boards and I'm seeing what must be an error in the USB Descriptors. The Device Descriptor says there are 2 Configurations, but both Configurations have the same bConfigurationValue - which is surely an illegal combination. When the Host sends a SetConfiguration message with a non-zero Configuration value, there must be a way to distinguish between the Configurations. For the example of a USB Audio Class Device with two Configurations, those values should be 1 and 2.
Perhaps the xCORE firmware was configured incorrectly when it was compiled, and that might explain why the Descriptors are conflicted. However, scanning through the firmware source, it seems that the bConfigurationValue fields are hard-coded when they should use macros or some other technique to adapt to the various combinations. i.e. The second bConfigurationValue should be 2 instead of 1.
Second, both Configuration structures are identical, which makes it seem pointless to have two of them. However, there is a comment in the source that seems to explain why there are two. In the file:
sw_usb_audio-[sw]_6.15.2rc1/sc_usb_audio/module_usb_audio/endpoint0/descriptors.h
/* Device Descriptor for Audio Class 2.0 (Assumes High-Speed ) */
USB_Descriptor_Device_t devDesc_Audio2 =
{
.bLength = sizeof(USB_Descriptor_Device_t),
.bDescriptorType = USB_DESCTYPE_DEVICE,
.bcdUSB = 0x0200,
.bDeviceClass = 0xEF,
.bDeviceSubClass = 0x02,
.bDeviceProtocol = 0x01,
.bMaxPacketSize0 = 64,
.idVendor = VENDOR_ID,
.idProduct = PID_AUDIO_2,
.bcdDevice = BCD_DEVICE,
.iManufacturer = offsetof(StringDescTable_t, vendorStr)/sizeof(char *),
.iProduct = offsetof(StringDescTable_t, productStr_Audio2)/sizeof(char *),
.iSerialNumber = 0,
.bNumConfigurations = 0x02 /* Set to 2 such that windows does not load composite driver */
};
I am worried by this comment because it implies that XMOS is violating the USB Specifications in order to whip Windows into shape with regard to the composite driver, and that seems like a really bad idea. Can anyone explain the reasoning behind this comment and the associated Descriptors? It seems like there must be a way to honor the USB Specifications and still have Windows work correctly.
I am also testing with macOS.
Brian Willoughby
Sound Consulting
Perhaps the xCORE firmware was configured incorrectly when it was compiled, and that might explain why the Descriptors are conflicted. However, scanning through the firmware source, it seems that the bConfigurationValue fields are hard-coded when they should use macros or some other technique to adapt to the various combinations. i.e. The second bConfigurationValue should be 2 instead of 1.
Second, both Configuration structures are identical, which makes it seem pointless to have two of them. However, there is a comment in the source that seems to explain why there are two. In the file:
sw_usb_audio-[sw]_6.15.2rc1/sc_usb_audio/module_usb_audio/endpoint0/descriptors.h
/* Device Descriptor for Audio Class 2.0 (Assumes High-Speed ) */
USB_Descriptor_Device_t devDesc_Audio2 =
{
.bLength = sizeof(USB_Descriptor_Device_t),
.bDescriptorType = USB_DESCTYPE_DEVICE,
.bcdUSB = 0x0200,
.bDeviceClass = 0xEF,
.bDeviceSubClass = 0x02,
.bDeviceProtocol = 0x01,
.bMaxPacketSize0 = 64,
.idVendor = VENDOR_ID,
.idProduct = PID_AUDIO_2,
.bcdDevice = BCD_DEVICE,
.iManufacturer = offsetof(StringDescTable_t, vendorStr)/sizeof(char *),
.iProduct = offsetof(StringDescTable_t, productStr_Audio2)/sizeof(char *),
.iSerialNumber = 0,
.bNumConfigurations = 0x02 /* Set to 2 such that windows does not load composite driver */
};
I am worried by this comment because it implies that XMOS is violating the USB Specifications in order to whip Windows into shape with regard to the composite driver, and that seems like a really bad idea. Can anyone explain the reasoning behind this comment and the associated Descriptors? It seems like there must be a way to honor the USB Specifications and still have Windows work correctly.
I am also testing with macOS.
Brian Willoughby
Sound Consulting