From: Jerome Brunet <jbrunet@baylibre.com>
To: Pavel Hofman <pavel.hofman@ivitera.com>
Cc: Ruslan Bilovol <ruslan.bilovol@gmail.com>,
Felipe Balbi <balbi@kernel.org>, Jack Pham <jackp@codeaurora.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-usb@vger.kernel.org
Subject: Re: [RFC PATCH 1/2] usb: gadget: uac2: fix maximum bandwidth calculation
Date: Tue, 05 Oct 2021 12:13:34 +0200 [thread overview]
Message-ID: <1jilybvjuw.fsf@starbuckisacylon.baylibre.com> (raw)
In-Reply-To: <8d291ef9-31a9-1b54-cc33-8c8550b59a88@ivitera.com>
On Tue 05 Oct 2021 at 12:00, Pavel Hofman <pavel.hofman@ivitera.com> wrote:
> Dne 05. 10. 21 v 11:37 Jerome Brunet napsal(a):
>> This fixes the wMaxPacketSize of the audio gadget so it is in line with
>> USB Audio Format specification - section 2.3.1.2.1
>> Cc: Jack Pham <jackp@codeaurora.org>
>> Cc: Pavel Hofman <pavel.hofman@ivitera.com>
>> Fixes: e89bb4288378 ("usb: gadget: u_audio: add real feedback implementation")
>> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
>> ---
>> There was a mistake in my previous mail, rounding depends on the
>> synchronisation, not the stream direction.
>> drivers/usb/gadget/function/f_uac2.c | 11 ++++++-----
>> 1 file changed, 6 insertions(+), 5 deletions(-)
>> diff --git a/drivers/usb/gadget/function/f_uac2.c
>> b/drivers/usb/gadget/function/f_uac2.c
>> index ae29ff2b2b68..c152efa30def 100644
>> --- a/drivers/usb/gadget/function/f_uac2.c
>> +++ b/drivers/usb/gadget/function/f_uac2.c
>> @@ -554,7 +554,7 @@ static int set_ep_max_packet_size(const struct f_uac2_opts *uac2_opts,
>> struct usb_endpoint_descriptor *ep_desc,
>> enum usb_device_speed speed, bool is_playback)
>> {
>> - int chmask, srate, ssize;
>> + int chmask, srate, ssize, spf;
>> u16 max_size_bw, max_size_ep;
>> unsigned int factor;
>> @@ -584,11 +584,12 @@ static int set_ep_max_packet_size(const struct
>> f_uac2_opts *uac2_opts,
>> ssize = uac2_opts->c_ssize;
>> }
>> - if (!is_playback && (uac2_opts->c_sync == USB_ENDPOINT_SYNC_ASYNC))
>> - srate = srate * (1000 + uac2_opts->fb_max) / 1000;
>> + if (uac2_opts->c_sync == USB_ENDPOINT_SYNC_ADAPTIVE)
>> + spf = DIV_ROUND_UP(srate, factor / (1 << (ep_desc->bInterval - 1)));
>> + else
>> + spf = (srate / (factor / (1 << (ep_desc->bInterval - 1)))) + 1;
>
> Please correct me if I am wrong, but does the change mean that
> uac2_opts->c_sync value has also impact on playback (EP-IN)
> wMaxPacketSize?
Duh :( - Thanks for catching this ! we only support async for playback
I guess you get the idea, I meant the rounding depends on the sync mode:
ADAPTIVE: spf = DIV_ROUND_UP(srate, factor / (1 << (ep_desc->bInterval - 1)));
ASYNC: spf = (srate / (factor / (1 << (ep_desc->bInterval - 1)))) + 1;
The important thing that you should round down for async (not up, as in
the patch you have sent)
Here is quick example with USB full speed
- ADAPTIVE:
* 48kHz: 48 samples/SIP (Service Interval Packet)
* 44.1kHz: max 45 samples/SIP
- ASYNC
* 48kHz: small SIP=47samples - big SIP=49samples
* 44.1kHz small SIP=44samples - big SIP=45samples
Your initial patch would not be correct for ASYNC@44.1kHz.
I think it would give a maximum size (big SIP) of 46 samples instead of
45.
>
> Thanks,
>
> Pavel.
>> - max_size_bw = num_channels(chmask) * ssize *
>> - DIV_ROUND_UP(srate, factor / (1 << (ep_desc->bInterval - 1)));
>> + max_size_bw = num_channels(chmask) * ssize * spf;
>> ep_desc->wMaxPacketSize = cpu_to_le16(min_t(u16, max_size_bw,
>> max_size_ep));
>>
next prev parent reply other threads:[~2021-10-05 10:36 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-05 8:44 [PATCH v2] usb: gadget: f_uac2: fixed EP-IN wMaxPacketSize Pavel Hofman
2021-10-05 8:59 ` Jerome Brunet
2021-10-05 9:37 ` [RFC PATCH 1/2] usb: gadget: uac2: fix maximum bandwidth calculation Jerome Brunet
2021-10-05 9:37 ` [RFC PATCH 2/2] usb: gadget: u_audio: remove fb_max Jerome Brunet
2021-10-05 10:00 ` [RFC PATCH 1/2] usb: gadget: uac2: fix maximum bandwidth calculation Pavel Hofman
2021-10-05 10:13 ` Jerome Brunet [this message]
2021-10-05 11:12 ` Pavel Hofman
2021-10-05 16:24 ` Jerome Brunet
2021-10-06 12:08 ` 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=1jilybvjuw.fsf@starbuckisacylon.baylibre.com \
--to=jbrunet@baylibre.com \
--cc=balbi@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=jackp@codeaurora.org \
--cc=linux-usb@vger.kernel.org \
--cc=pavel.hofman@ivitera.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