From: Pavel Hofman <pavel.hofman@ivitera.com>
To: "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>
Cc: Ruslan Bilovol <ruslan.bilovol@gmail.com>,
Felipe Balbi <balbi@kernel.org>,
Jerome Brunet <jbrunet@baylibre.com>,
Julian Scheel <julian@jusst.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
John Keeping <john@metanate.com>,
AKASH KUMAR <quic_akakum@quicinc.com>,
Jack Pham <jackp@codeaurora.org>
Subject: usb:gadget:f_uac2: RFC: allowing multiple altsetttings for channel/samplesize combinations
Date: Wed, 17 Apr 2024 13:07:28 +0200 [thread overview]
Message-ID: <35be4668-58d3-894a-72cf-de1afaacae45@ivitera.com> (raw)
Hi,
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?
Thanks a lot,
Pavel.
next reply other threads:[~2024-04-17 11:08 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-17 11:07 Pavel Hofman [this message]
2024-04-24 7:40 ` usb:gadget:f_uac2: RFC: allowing multiple altsetttings for channel/samplesize combinations Pavel Hofman
2024-04-25 9:22 ` Takashi Iwai
2024-04-25 15:07 ` Pavel Hofman
2024-04-28 15:30 ` Chris Wulff
2024-04-28 16:38 ` Chris Wulff
2024-04-29 15:02 ` Pavel Hofman
2024-04-30 18:51 ` Chris Wulff
2024-05-02 11:13 ` Pavel Hofman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=35be4668-58d3-894a-72cf-de1afaacae45@ivitera.com \
--to=pavel.hofman@ivitera.com \
--cc=alsa-devel@alsa-project.org \
--cc=balbi@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=jackp@codeaurora.org \
--cc=jbrunet@baylibre.com \
--cc=john@metanate.com \
--cc=julian@jusst.de \
--cc=linux-usb@vger.kernel.org \
--cc=quic_akakum@quicinc.com \
--cc=ruslan.bilovol@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).