[no subject]

>
>>> c) which PCM device is actually offloaded? This could be plural for some
>>> implementations. The mapping between PCM devices exposed by the USB
>>> card, and those exposed by the companion card, should be known to
>>> userspace. I am not sure how this would be done though, a variable
>>> number of controls is a sure way to confuse userspace.
>> Expanding on Amadeusz's suggestion, my idea is to have an enable/disable kcontrol per USB stream.  For example, one USB card could have multiple PCM devices (USB streams).  So we would have something like:
>>
>> PCM Offload Playback Enable Stream#0Â  enable/disable
>>
>> PCM Offload Playback Enable Stream#1Â  enable/disable
>>
>> ....
> are those read-only or not?

No, writable and readable.

>
>> So we'd know which USB card and PCM device is selected for USB SND.  However, I see what you're getting at in case there are multiple supported streams, because userspace needs to know which ASoC card/pcm combination corresponds to which USB device/combination.
> I don't understand how this would help map the two parts? There's got to
> be an additional mapping...
It won't help with the mapping.  That is something which we'd need to add, suggestion below.
>> What do you think about having a USB card kcontrol to display the mapped ASoC card and PCM indexes?
>>
>> PCM Offload Playback Enable Stream Mapping#0Â  0, 1 (ASoC card#0, PCM device#1)
>>
>> To summarize, if we did this, I'd plan to remove all the kcontrols in ASoC card, and have the following in the USB card for an USB audio device that supports one USB stream:
>>
>> PCM Offload Playback Enable Stream#0Â  enable/disable
>>
>> PCM Offload Playback Enable Stream Mapping#0Â  0, 1 (ASoC card#0, PCM device#1)
> ... which is suggested here.
>
> Assuming these are read-only controls, we would need to know which PCM
> device on the USB card can be optimized with the use of which PCM device
> on the ASoC card. That means a set of three values. You would also want
> a number of streams to make the guesswork on controls less painful.

OK, so now to just figuring out something that both you and Amadeusz can agree on before I put time implementing it.  So I've implemented the "enable/disable" path that Amadeusz suggested, which is highlighted in my previous response, for evaluation purposes.  The overall question is which layer should control the devices that will be offloaded.  In my submissions up until now, the control was given to the ASoC platform card to determine which USB device to offload.  Amadeusz mentioned that it might be beneficial to move the control to the USB SND devices, because what if the offloading is NOT backed by ASoC. (highlighted in [1])  However, IMO the current implementation assumes there is ASoC involved, which should mean that there is some platform "card" that is backing the offload path.  Please let me know if my understanding is incorrect, @Amadeusz. 

[1] - Re: [PATCH v23 32/32] ASoC: doc: Add documentation for SOC USB - Amadeusz SÅ?awiÅ?ski (kernel.org) <https://lore.kernel.org/linux-usb/510468c7-b181-48d0-bf2d-3e478b2f2aca@xxxxxxxxxxxxxxx/>

Thanks

Wesley Cheng