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@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. 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.
