Dne 21. 12. 21 v 13:29 John Keeping napsal(a):
On Mon, Dec 20, 2021 at 10:11:30PM +0100, Pavel Hofman wrote:
So far bInterval for HS and SS was fixed at 4, disallowing faster
samplerates. The patch determines the largest bInterval (4 to 1)
for which the required bandwidth of the max samplerate fits the
max allowed packet size. If the required bandwidth exceeds max
bandwidth for single-packet mode (ep->mc=1), bInterval is left at
1.
I'm not sure if this is desirable - there are more concerns around
the interval than just whether the bandwidth is available.
The nice thing about having the HS/SS interval at 4 when the FS
value is 1 is that these both correspond to 1ms, which means the
calculations for minimum buffer & period sizes are the same for
FS/HS/SS.
Please do you see any specific place in u_audio.c where the interval of
1ms is assumed?
* Buffer/period size max limits are fixed
* Bufer min size is calculated from the max_packet_size
* snd_pcm_period_elapsed() is called when the current request fill
overlaps the period boundary:
if ((hw_ptr % snd_pcm_lib_period_bytes(substream)) < req->actual)
snd_pcm_period_elapsed(substream);
The fixed HS bInterval=4 severely limits the available bandwidth,
disallowing even the very basic 192kHz/2ch/24bits config.
In f_uac2.c both HS/SS the max packet size, async EP OUT feedback value,
as well as async EP IN momentary packet size calculations already take
into account the bInterval of the respective endpoint.
I have been using bInterval < 4 in most of my tests for almost a year,
testing packet sizes at up to 1024 bytes per 125us uframe, both
directions, and the gadget has been bitperfect for samplerates up to
4MHz (including correctly working async feedback, tested on linux (up to
4MHz) and windows 10 WASAPI exclusive (up to 1.5MHz). For larger
samplerates tests I increased the buffers like in the patch below but I
did it just in case to minimize probability of xruns. It's not part of
this patchset and should be configured dynamically too, if actually
needed at all:
diff --git a/drivers/usb/gadget/function/u_audio.c
b/drivers/usb/gadget/function/u_audio.c
index 58e18952953b..1dedbf324141 100644
--- a/drivers/usb/gadget/function/u_audio.c
+++ b/drivers/usb/gadget/function/u_audio.c
@@ -23,8 +23,8 @@
#include "u_audio.h"
-#define BUFF_SIZE_MAX (PAGE_SIZE * 16)
-#define PRD_SIZE_MAX PAGE_SIZE
+#define BUFF_SIZE_MAX (PAGE_SIZE * 16 * 64)
+#define PRD_SIZE_MAX PAGE_SIZE * 64
#define MIN_PERIODS 4
enum {
diff --git a/drivers/usb/gadget/function/u_uac2.h
b/drivers/usb/gadget/function/u_uac2.h
index 8058217322f8..ae485913db46 100644
--- a/drivers/usb/gadget/function/u_uac2.h
+++ b/drivers/usb/gadget/function/u_uac2.h
@@ -30,7 +30,7 @@
#define UAC2_DEF_MAX_DB 0 /* 0 dB */
#define UAC2_DEF_RES_DB (1*256) /* 1 dB */
-#define UAC2_DEF_REQ_NUM 2
+#define UAC2_DEF_REQ_NUM 8
#define UAC2_DEF_INT_REQ_NUM 10
struct f_uac2_opts {
How do FS transfers work if the bandwidth requirements necessitate a
smaller interval for HS/SS? Doesn't that mean the FS transfers
must be too big?
Only UAC2 HS/SS bIntervals are dynamic with this patch, FS stays fixed
at 1ms. For HS/SS the max packet size is calculated together with the
bInterval, so that the largest bInterval possible to fit the ISOC max
packetsize limits is chosen.
I don't think there has ever been a check that the configured sample
size, channel count and interval actually fit in the max packet
size for an endpoint. Is that something that should be checked to
give an error on bind if the configuration can't work?
The existing code has never had checks for any of that. Actually the
dynamic bInterval calculation in this patch handles the bInterval and
packetsize for configured parameters up to maximum ISOC bandwidth. Next
version of this patch will at least warn about exceeding the overall
available bandwidth.
There are many patches to go before the audio gadget becomes fool-proof,
but at least it should be practically usable with these patches (when
finalized) and the gaudio controller example implementation.
I will send the new patchset version with notes for each patch hopefully
tomorrow.
Thanks a lot for your help,
Pavel.
