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

[Takashi Iwai <tiwai@suse.de>]

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


thanks,

Takashi