xmos / lib_xua

XMOS USB Audio
Other
17 stars 13 forks source link

Incorrect calculation for ENDPOINT_COUNT_IN when not using any inputs? #377

Closed mfreeborn closed 4 months ago

mfreeborn commented 6 months ago

I'm whittling down the sw_usb_audio reference application to configure it for our use case, which is basically just 2-channels USB out (from host to xmos device) and then passed through a DAC. I'm using asynchronous USB, NUM_USB_CHAN_IN 0 and NUM_USB_CHAN_OUT 2.

I'm configuring the USB endpoint tables and currently they look like this:

XUD_EpType epTypeTableOut[ENDPOINT_COUNT_OUT] = {
    XUD_EPTYPE_CTL | XUD_STATUS_ENABLE,  // Endpoint0
    XUD_EPTYPE_ISO,  // USB audio out from host
};

// ENDPOINT_COUNT_IN is 3 because XUA forces the inclusion of USB audio in
XUD_EpType epTypeTableIn[ENDPOINT_COUNT_IN] = {
    XUD_EPTYPE_CTL | XUD_STATUS_ENABLE,  // Endpoint0
    XUD_EPTYPE_ISO,  // Async feedback endpoint
};

However, ENDPOINT_COUNT_IN, calculated in xua_conf_default, reports as 3. Looking at the implementation:

enum USBEndpointNumber_In
{
    ENDPOINT_NUMBER_IN_CONTROL,     /* Endpoint 0 */
#if (NUM_USB_CHAN_IN == 0) || defined (UAC_FORCE_FEEDBACK_EP)
    ENDPOINT_NUMBER_IN_FEEDBACK,
#endif
    ENDPOINT_NUMBER_IN_AUDIO,   <---- What's this one for?

    <-- unused #defines redacted -->

    XUA_ENDPOINT_COUNT_IN           /* End marker */
};

The 3rd member of this enum, ENDPOINT_NUMBER_IN_AUDIO, seems to be responsible for ENDPOINT_COUNT_IN being 3. Should it not be gated by #if (NUM_USB_CHAN_IN == 0) statement?

xross commented 6 months ago

Thanks for the report, we'll get this fixed. I don't think it will cause any functional issue.