Re: usb:gadget:f_uac2: RFC: allowing multiple altsetttings for channel/samplesize combinations

[Pavel Hofman <pavel.hofman@ivitera.com>]

On 25. 04. 24 11:22, Takashi Iwai wrote:
> On Wed, 24 Apr 2024 09:40:52 +0200,
> Pavel Hofman wrote:
>>
>>
>> On 17. 04. 24 13:07, Pavel Hofman wrote:
>>
>>> I am considering implementation of multiple altsettings to f_uac2, so
>>> that multiple combinations of channels and samplesizes can be offered to
>>> the host.
>>>
>>> Configuration:
>>> --------------
>>> * each altsetting for each direction should define
>>>    * channel mask
>>>    * samplesize
>>>    * hs_bint bInterval
>>>    * c_sync type (for capture only)
>>>
>>>
>>> Perhaps the easiest config would be allowing lists for the existing
>>> parameters (like the multiple samplerates were implemented). All the
>>> list params would have to have the same number of items - initial check.
>>> First values in the list would apply to altsetting 1, second to
>>> altsetting 2 etc.
>>>
>>> Or the altsetting could be some structured configfs param - please is
>>> there any recommended standard for structured configfs params?
>>>
>>>
>>> Should the config also adjust the list of allowed samplerates for each
>>> altsetting? Technically it makes sense as higher number of channels can
>>> decrease the max samplerate, e.g. for via a TDM interface. If so, it
>>> would need either the structured configuration or some "list of lists"
>>> format.
>>>
>>>
>>> Implementation:
>>> ---------------
>>>
>>> Parameters could be turned to arrays of fixed predefined sizes, like the
>>> p/s_srates. E.g. 5 max. altsettings in each direction would consume only
>>> 4 * (5-1) + 3* (5-1) = 28 extra ints (excluding the samplerates config).
>>>
>>> Currently all descriptor structs are statically pre-allocated as there
>>> are only two hard-coded altsettings. IMO the descriptors specific for
>>> each altsetting could be allocated dynamically in a loop over all
>>> none-zero alsettings.
>>>
>>> Please may I ask UAC2 gadget "stakeholders" for comments, suggestions,
>>> recommendations, so that my eventual initial version was in some
>>> generally acceptable direction?
>>>
>>
>> This feature has coincidentally arisen in recent commits by Chris
>> https://lore.kernel.org/lkml/c9928edb-8b2d-1948-40b8-c16e34cea3e2@ivitera.com/T/
>>
>> Maybe Takashi's commits to the midi gadget could be a way
>> https://patchwork.kernel.org/project/alsa-devel/list/?series=769151&state=%2A&archive=both
>> The midi gadget allows multiple configurations now, where configs are
>> placed into a separate block.X configfs directory. That way the configfs
>> recommendation to keep one value per item is adhered to and the
>> configuration is nice and clean.
>>
>> This method would nicely allow various samplerate lists for each
>> altsetting, without having to use some obscure list of lists.
>>
>> The f_uac2 tree config could have e.g. alt.1-X subdirs, to fit the
>> altsetting ID. I am not sure the dot index not starting with 0 would be
>> an issue.
>>
>> Now the question would be what to do with the existing (and the new
>> params added by Chris) flat-structure parameters which apply to (the
>> only one) altsetting 1. Maybe they could be used as defaults for the
>> other altsettings for unspecified parameters?
>>
>> I very much appreciate any input, thank you all in advance.
> 
> IMO, a softer approach would be to use subdirs for alt1+ while flat
> files are kept used for alt0.

Thanks a lot for your help. IIUC almost all existing configs for the
UAC1/2 functions apply to the "run" altsetting - altsetting 1. The
altsetting 0 is for stopping the operation, IIUC. Actually that's how
the stream stop is detected on the gadget side - transition alt1 -> alt0.

Did you perhaps mean the first "running" altsetting?


>  Alternatively, we may allow creating
> alt0, too, and the values there will win over the flat values.
> 

IIUC this would be the meaning of default configs, in case they are not
specified in the subdir. I like that as it would make the configuration
easier if not generated by some script.

Thanks,

Pavel.