Pavel, Following up on this and discussions in this patch series https://lore.kernel.org/linux-usb/CO1PR17MB54195BE778868AFDFE2DCB36E1112@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/ Example from that thread with c_alt_name changed to c_name as it lives in an "alt.x" directory and removal of the num_alt_modes in favor of just allowing "mkdir alt.x" to create new alt mode settings: (all existing properties + the following new properties) c_it_name c_it_ch_name c_fu_name c_ot_name p_it_name p_it_ch_name p_fu_name p_ot_name alt.0 c_name p_name alt.1 (for alt.1, alt.2, etc.) c_name p_name c_ssize p_ssize (Additional properties here for other things that are settable for each alt mode, but the only one I've implemented in my prototype so far is sample size.) Here is a more detailed breakdown of the (current) proposal: * Allow the user to create "alt.x" directories inside uac1 and uac2 function configfs * Prior to creation of any of these alt.x subdirectories, the function behaves the same as it does today. No "alt.x" directories would exist on creation of the function. * Creation of "alt.0" contains only "c_name" and "p_name" to set the USB string name for this alt mode, with the defaults as "Capture Inactive" and "Playback Inactive" * Creation of "alt.x" where x is an integer, contains the same name strings but with defaults of "Capture Active" and "Playback Active" and additional files for any per-alt-mode configurable settings (such as c_ssize, p_ssize, etc.) At the time of creation, values for those are copied from the corresponding settings in the function main configfs directory. * Creation of "alt.1" in particular changes the meaning of the files in the main function configfs dir so that they are only _default_ values used when creating "alt.x" directories and settings from "alt.1" will now be used for alt mode 1. (Alt mode 1 always exists, even when "alt.1" has not been created.) * ALSA card interface behavior * Configuration of the ALSA card interface remains the same. It is configured when binding the function to match the settings in the main function configfs. "alt.x" settings have no effect on the created ALSA card setup * Sample size will be converted between ALSA and USB data by dropping extra bits or zero padding samples (eg 16->24 will zero pad a byte, 24->16 will drop a byte) * Channel count differences will ignore extra incoming channels and zero outgoing extra channels (eg 8->2 will just copy the first two and ignore the rest. 2->8 will copy the first two and zero the rest.) * Per-alt-mode configurable settings will have a read-only ALSA control (like sample rate does currently) that can be used to inform the program attached to the ALSA card what the current state of those settings are when the USB host selects an alt mode. An simple example of how this could be used to create a second alt mode: mkdir uac1.0 echo 24 > uac1.0/p_ssize echo 24 > uac1.0/c_ssize mkdir uac1.0/alt.2 echo 16 > uac1.0/alt.2/c_ssize NOTE: Alt modes are separately selectable by the host for playback and capture so the host can pick and choose as desired. There is no need to make an alt mode for every combination of playback and capture settings. In this example the host can pick either 24 or 16 bit samples for capture, but is only allowed 24 bit samples for playback as both alt.1 (via uac1.0/p_ssize) and alt.2 (via default copied to uac1.0/alt.2/p_ssize) have been configured as 24-bit. On Thu, Apr 25, 2024 at 11:08 AM Pavel Hofman <pavel.hofman@xxxxxxxxxxx> wrote: > > > 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. > >
