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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Pulse Audio]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux