On 1/31/23 20:40, Wesley Cheng wrote: > Hi Pierre, > > On 1/30/2023 3:59 PM, Pierre-Louis Bossart wrote: >> >> >> On 1/30/23 16:54, Wesley Cheng wrote: >>> Hi Pierre, >>> >>> On 1/26/2023 7:38 AM, Pierre-Louis Bossart wrote: >>>> >>>> >>>> On 1/25/23 21:14, Wesley Cheng wrote: >>>>> The QC ADSP is able to support USB playback endpoints, so that the >>>>> main >>>>> application processor can be placed into lower CPU power modes. This >>>>> adds >>>>> the required AFE port configurations and port start command to >>>>> start an >>>>> audio session. >>>>> >>>>> Specifically, the QC ADSP can support all potential endpoints that are >>>>> exposed by the audio data interface. This includes, feedback >>>>> endpoints >>>>> (both implicit and explicit) as well as the isochronous (data) >>>>> endpoints. >>>>> The size of audio samples sent per USB frame (microframe) will be >>>>> adjusted >>>>> based on information received on the feedback endpoint. >>>> >>>> I think you meant "support all potential endpoint types" >>>> >>>> It's likely that some USB devices have more endpoints than what the DSP >>>> can handle, no? >>>> >>> >>> True, as we discussed before, we only handle the endpoints for the audio >>> interface. Other endpoints, such as HID, or control is still handled by >>> the main processor. >> >> The number of isoc/audio endpoints can be larger than 1 per direction, >> it's not uncommon for a USB device to have multiple connectors on the >> front side for instruments, mics, monitor speakers, you name it. Just >> google 'motu' or 'rme usb' and you'll see examples of USB devices that >> are very different from plain vanilla headsets. >> > > Thanks for the reference. > > I tried to do some research on the RME USB audio devices, and they > mentioned that they do have a "class compliant mode," which is for > compatibility w/ Linux hosts. I didn't see a vendor specific USB SND > driver matching the USB VID/PID either, so I am assuming that it uses > the USB SND driver as is.(and that Linux doesn't currently support their > vendor specific mode) In that case, the device should conform to the > UAC2.0 spec (same statement seen on UAC3.0), which states in Section > 4.9.1 Standard AS Interface Descriptor Table 4-26: > > "4 bNumEndpoints 1 Number Number of endpoints used by this > interface (excluding endpoint 0). Must be > either 0 (no data endpoint), 1 (data > endpoint) or 2 (data and explicit feedback > endpoint)." > > So each audio streaming interface should only have 1 data and > potentially 1 feedback. However, this device does expose a large number > of channels (I saw up to 18 channels), which the USB backend won't be > able to support. I still need to check how ASoC behaves if I pass in a > profile that the backend can't support. > > Maybe in the non-class compliant/vendor based class driver, they have > the support for multiple EPs per data interface? I don't have one of > these devices on hand, so I can't confirm that. Look at Figure 3-1 in the UAC2 spec, it shows it's perfectly legal to have multiple Audio Streaming interfaces - but one Audio Control interface only. The fact that there is a restriction to 1 or 2 endpoints per Audio Streaming interface does not really matter if in the end there are multiple endpoints and concurrent isoc transfers happening to/from the same USB device.
