[wdmaudiodev] Re: Asynchronous sink feedback question

  • From: Chris Fryer <chris@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
  • To: wdmaudiodev@xxxxxxxxxxxxx
  • Date: Wed, 21 Apr 2021 17:21:06 +0100

That's a trade of latency vs cpu load as far as I understand.

On 21/04/2021 17:10, Wade Dawson wrote:

With bInterval = 4 on your data (streaming) EPs, aren’t you telling the host that you only want an iso transfer every 16 uFrames or 2ms?  Why did you choose that? Don’t you want 1 transfer per uFrame?

*From: *wdmaudiodev-bounce@xxxxxxxxxxxxx <wdmaudiodev-bounce@xxxxxxxxxxxxx>
*Date: *Wednesday, April 21, 2021 at 12:05 PM
*To: *wdmaudiodev@xxxxxxxxxxxxx <wdmaudiodev@xxxxxxxxxxxxx>
*Subject: *[wdmaudiodev] Re: Asynchronous sink feedback question

No problem, I appreciate the co-operation.

bInterval is 4 for the feedback and data EPs.

Yes I found the implicit FB attributes from this Apple tech note. It made no difference to Windows operation.
https://developer.apple.com/library/archive/technotes/tn2274/_index.html#//apple_ref/doc/uid/DTS40010116-CH1-TNTAG4_3 <https://developer.apple.com/library/archive/technotes/tn2274/_index.html#//apple_ref/doc/uid/DTS40010116-CH1-TNTAG4_3>

On 21/04/2021 16:48, Wade Dawson wrote:

    Well, Chris, I did start off telling you I was confused by that…
    Sorry for the incorrect info, looks like you’re right about it. 
    Also, based on this:


    the MS UAC2 driver doesn’t support implicit FB. (Though our
    devices still “work” with the class driver and have no FB EPs)


    1.What are you setting bInterval to on the feedback EP?  I would
    guess 0 (1uFrame)?  Have you tried setting it to 3 (8uFrames)?
      The driver may just be doing 3.  (Windows doesn’t allow iso
    transfers of  < 8 uFrames currently so updating the fraction every
    uFrame is pointless since you can’t respond with a granularity of
    < 8 uFrames.)

    2.When you removed the EP, did you also set bmAttributes 5..4 =
    b’10’ to indicate implicit FB?

    FWIW, we’ve long stopped implementing iso feedback EPs in our
    devices and rely solely on implicit sync or async, though we do
    have separate in and out interfaces.

    *From: *wdmaudiodev-bounce@xxxxxxxxxxxxx
    *Date: *Wednesday, April 21, 2021 at 11:03 AM
    *To: *wdmaudiodev@xxxxxxxxxxxxx <mailto:wdmaudiodev@xxxxxxxxxxxxx>
    <wdmaudiodev@xxxxxxxxxxxxx> <mailto:wdmaudiodev@xxxxxxxxxxxxx>
    *Subject: *[wdmaudiodev] Re: Asynchronous sink feedback question

    I don't know yet but I've just seen that the linux kernel is about
    to implement the same interpretation as I have for feedback in HS

    +static void u_audio_set_fback_frequency(enum usb_device_speed speed,

    +                               unsigned int freq, void *buf)


    + u32 ff = 0;


    + if (speed == USB_SPEED_FULL) {

    +        /*

    +         * Full-speed feedback endpoints report frequency

    +         * in samples/microframe

    +         * Format is encoded in Q10.10 left-justified in the 24 bits,

    +         * so that it has a Q10.14 format.

    +         */

    +        ff = DIV_ROUND_UP((freq << 14), 1000);

    + } else {

    +        /*

    +         * High-speed feedback endpoints report frequency

    +         * in samples/microframe.

    +         * Format is encoded in Q12.13 fitted into four bytes so that

    +         * the binary point is located between the second and the

    +         * byte fromat (that is Q16.16)

    +         *

    +         * Prevent integer overflow by calculating in Q12.13
    fromat and

    +         * then shifting to Q16.16

    +         */

    +        ff = DIV_ROUND_UP((freq << 13), (8*1000)) << 3;

    + }

    + *(__le32 *)buf = cpu_to_le32(ff);



    On 21/04/2021 15:51, Wade Dawson wrote:

        Hi Chris. What does MacOs think about that change?

        *From: *wdmaudiodev-bounce@xxxxxxxxxxxxx
        *Date: *Wednesday, April 21, 2021 at 5:23 AM
        *To: *wdmaudiodev@xxxxxxxxxxxxx
        <mailto:wdmaudiodev@xxxxxxxxxxxxx> <wdmaudiodev@xxxxxxxxxxxxx>
        *Subject: *[wdmaudiodev] Re: Asynchronous sink feedback question

        Thanks Wade but I must be missing something because 5.12 seems
        fairly clear to me that Ff on a high speed endpoint should be
        samples per microframe?

        The standard says (5.12 Special Considerations for Isochronous
        /"Note: The examples in this section describe USB for an
        example involving full-speed endpoints. The
        general example details are also appropriate for high-speed
        endpoints when corresponding changes are
        made; for example, frame replaced with microframe, 1 ms
        replaced with 125 μ s, rate adjustments made
        between full-speed and high-speed, etc."

        /Then every reference to frame in the Feedback section is
        written as (micro)frame
        /"F//f is expressed in number of samples per (micro)frame. The
        F//f value consists of an integer part that
        represents the (integer) number of samples per (micro)frame
        and a fractional part that represents the
        “fraction” of a sample that would be needed to match the
        sampling frequency F//s to a resolution of 1 Hz or

        I read the section on implicit feedback for asynchronous sinks
        ( <> Implicit Feedback):
        /"One or more asynchronous sink endpoints are accompanied by
        an asynchronous source endpoint. The
        data rate on the source endpoint can be used as implicit
        feedback information to adjust the data rate on
        the sink endpoint(s)."/

        I have an asynchronous sink endpoint and an asynchronous
        source endpoint in the same interface so I  simply removed the
        explicit feedback endpoint:
        [1]0004.0108::04/21/2021-08:35:06.229 [USBAudio2](0x0101): AS
        interface with bInterfaceNumber=0x01 bAlternateSetting=0x01
        uses asynch synchronization but does not implement a feedback
        [1]0004.0108::04/21/2021-08:35:06.229 [USBAudio2](0x01):
        Create failed NTSTATUS=C0440025

        That suggests usbaudio2.sys does not look to implement
        implicit feedback. Is that right?


        On 20/04/2021 17:42, Wade Dawson wrote:

            I’ve been confused by that as well.  The fraction is
            relative to frame (1ms) not microframe (125uS), so 48 is
            correct. I’m fairly certain the Windows UAC2 driver will
            do implicit feedback, no?  I.e., no feedback EP?  The osx
            driver does for sure.


            *From: *wdmaudiodev-bounce@xxxxxxxxxxxxx
            *Date: *Tuesday, April 20, 2021 at 10:09 AM
            *To: *wdmaudiodev@xxxxxxxxxxxxx
            <wdmaudiodev@xxxxxxxxxxxxx> <mailto:wdmaudiodev@xxxxxxxxxxxxx>
            *Subject: *[wdmaudiodev] Asynchronous sink feedback question

            My understanding of the USB 2.0 spec (section
            <http://sdpha2.ucsd.edu/Lab_Equip_Manuals/usb_20.pdf> for
            asynchronous sinks was that the sink in high speed mode
            should provide feedback of Ff formatted as a 16.16 number
            where Ff is the number of samples per _micro_ frame (125us

            A 48kHz sink will then return values close to 6.0
            (0x00060000 in 16.16 format).

            We implemented this and tested some time ago on Windows 10
            1903 (or similar). Testing with Windows 10 20 2H we're
            seeing audio glitches.

            Event logs tell us that the driver is ignoring the
            feedback values because they're out of range:
            [0]0004.01C4::04/20/2021-13:36:16.321 [USBAudio2]feedback
            value 0x00062000 is out of range [0x002f0000,0x00310000],
            ignoring value
            [0]0004.01C4::04/20/2021-13:36:16.321 [USBAudio2]feedback
            value 0x0005e000 is out of range [0x002f0000,0x00310000],
            ignoring value
            [0]0004.01C4::04/20/2021-13:36:16.321 [USBAudio2]feedback
            value 0x00062000 is out of range [0x002f0000,0x00310000],
            ignoring value
            [0]0004.01C4::04/20/2021-13:36:16.321 [USBAudio2]feedback
            value 0x00062000 is out of range [0x002f0000,0x00310000],
            ignoring value

            It appears the driver wants a value close to 48.0 which
            would be samples per frame instead of samples per micro frame.

            Have I misinterpreted the spec?

            I didn't investigate to this detail on the previous
            release of Windows. I can see this is a new release of
            usbaudio2.sys. Is this a new check?

            I have tried reporting samples per frame and the glitches
            stop on Windows 10 but MacOS then glitches.

            Any hints gratefully received!

            ChrisHi Chris.

Other related posts: