[wdmaudiodev] Re: Asynchronous sink feedback question

  • From: "geert@xxxxxxxxxxxxxxxxxxx" <geert@xxxxxxxxxxxxxxxxxxx>
  • To: wdmaudiodev@xxxxxxxxxxxxx
  • Date: Wed, 21 Apr 2021 08:54:25 -0700

We are working on corrective language fort he spec to say “samples per Service 
Interval”…

Stay tuned.

Kindest Regards,

  <http://www.designandadvice.com/>  <http://www.jwhouse.org/>Geert Knapen 
President/Owner

Design & Advice, L.L.C. <http://www.designandadvice.com/>
1725 Martin Avenue, San Jose CA 95128
e-mail: geert@xxxxxxxxxxxxxxxxxxx <mailto:geert@xxxxxxxxxxxxxxxxxxx> | Tel: 
+1-408-297-3731 | Cell: +1-408-507-7852 | Google Voice: +1-408-805-4320

On Apr 21, 2021, at 8:03 AM, Chris Fryer <chris@xxxxxxxxxxxxxxxxxxxxxxxxxxx> 
wrote:

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

+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 third
+              * 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);
+}

https://www.spinics.net/lists/linux-usb/msg204221.html
 <https://www.spinics.net/lists/linux-usb/msg204221.html>

On 21/04/2021 15:51, Wade Dawson wrote:
Hi Chris.  What does MacOs think about that change?
 
From: wdmaudiodev-bounce@xxxxxxxxxxxxx 
<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx> <wdmaudiodev-bounce@xxxxxxxxxxxxx> 
<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
Date: Wednesday, April 21, 2021 at 5:23 AM
To: wdmaudiodev@xxxxxxxxxxxxx <mailto:wdmaudiodev@xxxxxxxxxxxxx
<wdmaudiodev@xxxxxxxxxxxxx> <mailto: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 Transfers):
"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
"Ff is expressed in number of samples per (micro)frame. The Ff 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 
Fs to a resolution of 1 Hz or
better."

I read the section on implicit feedback for asynchronous sinks (5.12.4.3 
<http://5.12.4.3/> 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 endpoint
[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?

Regards
Chris

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.
 
-Wade.
 
From: wdmaudiodev-bounce@xxxxxxxxxxxxx 
<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx> <wdmaudiodev-bounce@xxxxxxxxxxxxx> 
<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
Date: Tuesday, April 20, 2021 at 10:09 AM
To: wdmaudiodev@xxxxxxxxxxxxx <mailto:wdmaudiodev@xxxxxxxxxxxxx
<wdmaudiodev@xxxxxxxxxxxxx> <mailto:wdmaudiodev@xxxxxxxxxxxxx>
Subject: [wdmaudiodev] Asynchronous sink feedback question

My understanding of the USB 2.0 spec (section 5.12.4.2 Feedback) 
<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 
period).

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!

Regards
ChrisHi Chris.

Other related posts: