>>>>> + * @list - list head for SoC USB devices
>>>>> + **/
>>>>> +struct snd_soc_usb_device {
>>>>> + int card_idx;
>>>>> + int pcm_idx;
>>>>> + int chip_idx;
>>>>> + int num_playback;
>>>>> + int num_capture;
>>>>> + struct list_head list;
>>>>> +};
>>>>> +
>>>>> +/**
>>>>> + * struct snd_soc_usb
>>>>> + * @list - list head for SND SOC struct list
>>>>> + * @component - reference to ASoC component
>>>>> + * @num_supported_streams - number of supported concurrent sessions
>>>> ... but here we don't. And it's not clear what the working 'sessions'
>>>> means in the comment.
>
> After taking a look at this "num_supported_streams" naming a bit more, I wanted to check with you to see adds to the complexity of the terminology being used across soc-usb.
>
> The intention of this is to define how many concurrent USB devices the USB backend can support. So for example, if the audio DSP did support multiple USB devices at the same time, this would denote that. This is where I wanted to make sure the terminology was right.... So in this case, to me, it makes more sense if num_supported_streams --> num_supported_devices, because it determines how many USB devices the ASoC USB backend DAI can manage/support. This adds a bit to the reason why I think using the term "port" for explaining the SOC USB context is reasonable.
IIRC the USB specs define a hierarchy of device/interface/endpoint
concepts. For streaming the only thing that really matters is the number
of data endpoints, isn't it? If you have two devices with a single
endpoint each or one device with two endpoints it should be the same
complexity at the DSP level?
