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@xxxxxxxxxxx/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. Alternatively, we may allow creating alt0, too, and the values there will win over the flat values. thanks, Takashi
