Date: Thu, 20 Jun 2024 15:04:04 -0700
From: Wesley Cheng <quic_wcheng@...cinc.com>
To: Amadeusz Sławiński
	<amadeuszx.slawinski@...ux.intel.com>,
        <srinivas.kandagatla@...aro.org>, <mathias.nyman@...el.com>,
        <perex@...ex.cz>, <conor+dt@...nel.org>, <corbet@....net>,
        <broonie@...nel.org>, <lgirdwood@...il.com>, <krzk+dt@...nel.org>,
        <Thinh.Nguyen@...opsys.com>, <bgoswami@...cinc.com>, <tiwai@...e.com>,
        <robh@...nel.org>, <gregkh@...uxfoundation.org>
CC: <linux-kernel@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-sound@...r.kernel.org>, <linux-usb@...r.kernel.org>,
        <linux-arm-msm@...r.kernel.org>, <linux-doc@...r.kernel.org>,
        <alsa-devel@...a-project.org>
Subject: Re: [PATCH v23 32/32] ASoC: doc: Add documentation for SOC USB

Hi Amaduesz,

On 6/19/2024 12:52 AM, Amadeusz Sławiński wrote:
> On 6/18/2024 10:52 PM, Wesley Cheng wrote:
>> Hi Amadeusz,
>>
>> On 6/18/2024 4:42 AM, Amadeusz Sławiński wrote:
>>> On 6/17/2024 7:02 PM, Wesley Cheng wrote:
>>>> Hi Amadeusz,
>>>>
>>>> On 6/13/2024 12:46 AM, Amadeusz Sławiński wrote:
>>>>> On 6/12/2024 9:28 PM, Wesley Cheng wrote:
>>>>>> Hi Amadeusz,
>>>>>>
>>>>>> On 6/12/2024 7:47 AM, Amadeusz Sławiński wrote:
>>>>>>> On 6/11/2024 1:58 AM, Wesley Cheng wrote:
>>>>>>>
>>>>>>> (...)
>>>>>>>
>>>>>>>> +In the case where the USB offload driver is unbounded, while 
>>>>>>>> USB SND is
>>>>>>>
>>>>>>> unbounded -> unbound
>>>>>>>
>>>>>>> (...)
>>>>>>>
>>>>>>>> +SOC USB and USB Sound Kcontrols
>>>>>>>> +===============================
>>>>>>>> +Details
>>>>>>>> +-------
>>>>>>>> +SOC USB and USB sound expose a set of SND kcontrols for 
>>>>>>>> applications to select
>>>>>>>> +and fetch the current offloading status for the ASoC platform 
>>>>>>>> sound card. Kcontrols
>>>>>>>> +are split between two layers:
>>>>>>>> +
>>>>>>>> +    - USB sound - Notifies the sound card number for the ASoC 
>>>>>>>> platform sound
>>>>>>>> +      card that it is registered to for supporting audio offload.
>>>>>>>> +
>>>>>>>> +    - SOC USB - Maintains the current status of the offload 
>>>>>>>> path, and device
>>>>>>>> +      (USB sound card and PCM device) information.  This would 
>>>>>>>> be the main
>>>>>>>> +      card that applications can read to determine offloading 
>>>>>>>> capabilities.
>>>>>>>> +
>>>>>>>> +Implementation
>>>>>>>> +--------------
>>>>>>>> +
>>>>>>>> +**Example:**
>>>>>>>> +
>>>>>>>> +  **Sound Cards**:
>>>>>>>> +
>>>>>>>> +    ::
>>>>>>>> +
>>>>>>>> +      0 [SM8250MTPWCD938]: sm8250 - 
>>>>>>>> SM8250-MTP-WCD9380-WSA8810-VA-D
>>>>>>>> +                     SM8250-MTP-WCD9380-WSA8810-VA-DMIC
>>>>>>>> +      1 [C320M          ]: USB-Audio - Plantronics C320-M
>>>>>>>> +                     Plantronics Plantronics C320-M at 
>>>>>>>> usb-xhci-hcd.1.auto-1, full speed
>>>>>>>> +
>>>>>>>> +
>>>>>>>> +  **Platform Sound Card** - card#0:
>>>>>>>> +
>>>>>>>> +    ::
>>>>>>>> +
>>>>>>>> +      USB Offload Playback Route Card Select  1 (range -1->32)
>>>>>>>> +      USB Offload Playback Route PCM Select   0 (range -1->255)
>>>>>>>> +      USB Offload Playback Route Card Status  -1 (range -1->32)
>>>>>>>> +      USB Offload Playback Route PCM Status   -1 (range -1->255)
>>>>>>>> +
>>>>>>>> +
>>>>>>>> +  **USB Sound Card** - card#1:
>>>>>>>> +
>>>>>>>> +    ::
>>>>>>>> +
>>>>>>>> +      USB Offload Playback Capable Card         0 (range -1->32)
>>>>>>>> +
>>>>>>>> +
>>>>>>>> +The platform sound card(card#0) kcontrols are created as part 
>>>>>>>> of adding the SOC
>>>>>>>> +USB device using **snd_soc_usb_add_port()**.  The following 
>>>>>>>> kcontrols are defined
>>>>>>>> +as:
>>>>>>>> +
>>>>>>>> +  - ``USB Offload Playback Route Card Status`` **(R)**: USB 
>>>>>>>> sound card device index
>>>>>>>> +    that defines which USB SND resources are currently 
>>>>>>>> offloaded. If -1 is seen, it
>>>>>>>> +    signifies that offload is not active.
>>>>>>>> +  - ``USB Offload Playback Route PCM Status`` **(R)**: USB PCM 
>>>>>>>> device index
>>>>>>>> +    that defines which USB SND resources are currently 
>>>>>>>> offloaded. If -1 is seen, it
>>>>>>>> +    signifies that offload is not active.
>>>>>>>> +  - ``USB Offload Playback Route Card Select`` **(R/W)**: USB 
>>>>>>>> sound card index which
>>>>>>>> +    selects the USB device to initiate offloading on.  If no 
>>>>>>>> value is written to the
>>>>>>>> +    kcontrol, then the last USB device discovered card index 
>>>>>>>> will be chosen.
>>>>>>>
>>>>>>> I see only one kcontrol, what if hardware is capable of 
>>>>>>> offloading on more cards, is it possible to do offloading on more 
>>>>>>> than one device?
>>>>>>>
>>>>>>>> +  - ``USB Offload Playback Route PCM Select`` **(R/W)**: USB 
>>>>>>>> PCM index which selects
>>>>>>>> +    the USB device to initiate offloading on.  If no value is 
>>>>>>>> written to the
>>>>>>>> +    kcontrol, then the last USB device discovered PCM zero 
>>>>>>>> index will be chosen.
>>>>>>>> +
>>>>>>>> +The USB sound card(card#1) kcontrols are created as USB audio 
>>>>>>>> devices are plugged
>>>>>>>> +into the physical USB port and enumerated.  The kcontrols are 
>>>>>>>> defined as:
>>>>>>>> +
>>>>>>>> +  - ``USB Offload Playback Capable Card`` **(R)**: Provides the 
>>>>>>>> sound card
>>>>>>>> +    number/index that supports USB offloading.  Further/follow 
>>>>>>>> up queries about
>>>>>>>> +    the current offload state can be handled by reading the 
>>>>>>>> offload status
>>>>>>>> +    kcontrol exposed by the platform card.
>>>>>>>> +
>>>>>>>
>>>>>>>
>>>>>>> Why do we need to some magic between cards? I feel like whole 
>>>>>>> kcontrol thing is overengineered a bit - I'm not sure I 
>>>>>>> understand the need to do linking between cards. It would feel a 
>>>>>>> lot simpler if USB card exposed one "USB Offload" kcontrol on USB 
>>>>>>> card if USB controller supports offloading and allowed to set it 
>>>>>>> to true/false to allow user to choose if they want to do 
>>>>>>> offloading on device.
>>>>>>>
>>>>>>> (...)
>>>>>>
>>>>>> Based on feedback from Pierre, what I understood is that for some 
>>>>>> applications, there won't be an order on which sound card is 
>>>>>> queried/opened first.
>>>>>>
>>>>>
>>>>> Yes if you have multiple cards, they are probed in random order.
>>>>>
>>>>>> So the end use case example given was if an application opened the 
>>>>>> USB sound card first, it can see if there is an offload path 
>>>>>> available. If there is then it can enable the offload path on the 
>>>>>> corresponding card if desired.
>>>>>>
>>>>>
>>>>> This still doesn't explain why you need to link cards using 
>>>>> controls. What would not work with simple "Enable Offload" with 
>>>>> true/false values on USB card that works while you do have above 
>>>>> routing controls?
>>>>>
>>>>
>>>> Sorry for the late response.
>>>>
>>>> I think either way, even with the "Enable Offload" kcontrol in USB 
>>>> SND, we'd need a way to link these cards, because if you have 
>>>> multiple USB audio devices connected, and say... your offload 
>>>> mechanism only supports one stream.  Then I assume we'd still need 
>>>> to way to determine if that stream can be enabled for that USB SND 
>>>> device or not.
>>>>
>>>> Since the USB SND isn't really the entity maintaining the offload 
>>>> path, I went with the decision to add that route selection to the 
>>>> ASoC platform card. It would have access to all the parameters 
>>>> supported by the audio DSP.
>>>>
>>>
>>> Problem with card selection is that it will most likely work in 
>>> pretty random way during reboots and similar scenarios.
>>>
>>> Taking from your example:
>>>      USB Offload Playback Route Card Select  1 (range -1->32)
>>>      USB Offload Playback Route PCM Select   0 (range -1->255)
>>>      USB Offload Playback Route Card Status  -1 (range -1->32)
>>>      USB Offload Playback Route PCM Status   -1 (range -1->255)
>>>
>>> This tells that hw:1,0 will be offloaded USB card. What happens if 
>>> after reboot the USB card and offload card change places, the control 
>>> will be pointing at its owner... Another scenario to consider is that 
>>> user attaches two USB cards and only first one does offload. Now what 
>>> happens when they enumerate in different order after reboot (swapping 
>>> places)? Taking into the account that most systems restore previous 
>>> values of controls in some way - this will point at wrong card.
>>
>> That sounds like a problem that would exist with current USB SND 
>> implementation too?  Removing the offloading perspective, how does the 
>> system ensure that the previous setting stays persistent?  For 
>> example, as you mentioned, depending on which USB device enumerates 
>> first, the sound card may be different so cards will be switched.
>>
> 
> It works because there is no control pointing at other card. My main 
> problem is with controls which have card and pcm id of other card in it.
> 
>> I think I mentioned this previously in another discussion, but I think 
>> the idea was that with the
>> USB Offload Playback Capable Card
>>
>> kcontrol, would allow the system to at least know there is an offload 
>> capable path pointing to the ASoC platform card, and fetch more 
>> detailed information about which device is selected for offloading, 
>> etc...
>>
> 
> This works only in your design, where USB Offload is backed by card, 
> what happens if it is backed by something else?
> 
>>>
>>> In my opinion Offload capability should be the capability of the 
>>> endpoint - in this case USB card (even if in the background it needs 
>>> to talk to some other device) and it should be exposed as such. 
>>> Currently you are mixing capabilities of your audio card with 
>>> capabilities of USB card.
>>>
>>> And adding more controls will not make it easy to use from end user 
>>> perspective. Most users will most likely want for the devices to 
>>> perform offload automatically if possible to save power and just have 
>>> control to disable it in case they want to test if it works better 
>>> without it in case of some problems.
>>
>> I agree with you that we need to keep the controls at a minimum, but I 
>> think what I have in place is fairly reasonable.  If we switch to 
>> having the USB SND controlling things, we'd save maybe one control?  I 
>> think keeping the offload status controls are still fairly valuable in 
>> both scenarios, as userspace may need to verify which USB SND card is 
>> being offloaded.
>>
> 
> It should be able to tell which one is being offloaded by examining 
> which USB card has Offload control set to true.
> 
> I would assume that USB cards that cannot perform Offload have no 
> control at all, as it is unneeded. And ones that can do, have Offload 
> control. And ones actively being Offloaded have it set to true, 
> otherwise to false.
> 
> End user has no need to know where it is offloaded. I'm not HW person, 
> but I would assume that it is even unlikely that someone will design HW, 
> where it is possible to Offload one endpoint to two different places, as 
> this complicates things a lot, but if it were possible, from design 
> perspective it would make a lot more sense to set it in Offloaded USB 
> card settings, instead of some seemingly unrelated controller card 
> device. And that is assuming that all solutions use some other card 
> device to perform Offload.
> 
>>>
>>> Additional question what happens if you want to offload two usb 
>>> cards, currently the above set of controls allows you to only point 
>>> at one card, will you be adding additional set of above controls 
>>> dynamically for each USB card attached?
>>>
>>
>> It would depend on the number of offload streams that folks may be 
>> supporting on their platform.  In our case we only have one available 
>> stream, so applications would need to switch between the two devices 
>> using the card/pcm selector.
>>
>> In this case, there will be only one set of controls to select the 
>> card/pcm device.  As of now (I think I'll change to to add another 
>> separate set of controls per stream) if you did support multiple 
>> streams, then the current card/PCM device selector would take in 
>> multiple arugments. (ie for two streams the kcontrol can take in two 
>> values)
>>
> 
> Then it is implementation detail of your device, and it should be 
> implemented as controls in your device instead of as part of generic API.
> 

I initially had it as part of the device specific files, but I did get 
some feedback on [1], it might be better to have generic control names, 
hence the reason for moving into soc-usb.

I'll spend some time to evaluate your suggestion about moving the logic 
to control the offloading from USB SND versus ASoC, since there are 
valid points.  However, before I do that, I just want to make sure folks 
are also inline with that thinking.  I've had to put a lot of effort 
moving things around such as the previous example, and now you've 
suggested to move it back to the vendor specific drivers.

@Pierre, since you've helped with providing a lot of valuable input in 
the previous revisions on the kcontrol uses, what do you think about the 
proposal from Amadeusz?  Basically shifting the offload device selection 
into USB SND from the ASoC USB BE driver, and having this per USB SND 
device.

[1] 
https://lore.kernel.org/linux-usb/20231017200109.11407-30-quic_wcheng@quicinc.com/

Powered by blists - more mailing lists