• Registered: 2021-11-21
  • Posts: 3

Topic: UCX II USB configuration issue for 20ch and 16ch wMaxPacketSize?

Hi,

UCX II supports 20, 16, 14, and 8ch playback, as defined by its USB alternate settings, all at samplerates up to 192kHz.

Altsetting 3 for 14ch  defines 

wMaxPacketSize     0x0a4c  2x 588 bytes

The 2 transactions each 588 bytes large at bInterval=1 give max. samplerate bandwidth of

2 x 588 x 8000 / 14 / 3 = 224kHz max. samplerate = 192kHz + nice async mode headroom.

And indeed linux plays fine at 192kHz/14ch/24bits, logging correct max packet size of 1176 bytes per microframe, with the explicit async feedback working perfectly.

However the 16ch and 20ch modes stutter at 192kHz. Their wMaxPacketSize values do not specify the 2 transactions, thus not reserving enough bandwidth:

        wMaxPacketSize     0x030c  1x 780 bytes
...
        wMaxPacketSize     0x0270  1x 624 bytes

Simple bandwidth calculation suggests the "1 additional transaction" bit is missing in the wMaxPacketSize fields of altsetting 1 (20ch) and 2 (16ch).

2 x 780 x 8000 / 20 / 3 = 208kHz

2 x 624 x 8000 / 16 / 3 = 208kHz

Perhaps setting the 11th bit in wMaxPacketSize for the 20ch and 16ch altsettings would fix the playback, just like it works for the 14ch altsetting. From outside view it looks just like a typo in the firmware.

For 20ch:
0x030c -> 0x0b0c

For 16ch:
0x0270 -> 0x0a70

More info is in https://www.diyaudio.com/forums/pc-base … ost6851858 and several following posts.

Thanks a lot for looking at this issue.

Best regards,

Pavel.

2 Reply by MC

  • MC
  • MC
  • Administrator
  • Offline
  • From: Germany/Thailand
  • Registered: 2007-04-06
  • Posts: 24,818

Re: UCX II USB configuration issue for 20ch and 16ch wMaxPacketSize?

Hello Pavel,

- At 192 kHz sample rate, the UCX II has only 14 channels in and out.

- The first 20 channel format is mainly intended to be used at single sample rates (iPad). The fact that it also supports 96 kHz is mainly a feature for the iPad, the last channels are ignored then.

- The second 16 channel format is for double speed (up to 96 kHz), the third 14 channel format then for quad speed (up to 192 kHz)

- The fourth 8 channel format supports all sample rates

Trying to use the 16 channel format at 192 kHz won't work (see above). On a Mac you can not select this, as the Mac OS CC driver notices that the bandwidth is not sufficient for 192 kHz.

Regards
Matthias Carstens
RME

MC's Website

  • Registered: 2021-11-21
  • Posts: 3

Re: UCX II USB configuration issue for 20ch and 16ch wMaxPacketSize?

Hi Matthias,

Thank you for your response.

Are the limitations you describe caused by internal circuits of the device or by the available bandwidth? If the cause is presumably the bandwidth, then I do not understand that the 14ch altsetting requests and successfully uses two transactions per microframe (2 x 588 bytes = 1176 bytes, exceeding the max. ISOC packet size 1024 bytes but using two of them), while the 16ch and 20ch modes request only one transaction/packet which obviously does not reserve sufficient bandwidth. If they requested two transactions (like the 14ch mode already does), the reserved bandwidth would perfectly suffice for 192kHz plus some async overhead - the simple calculations in my first post show that.

As I said, from the outside view the discrepancy between 2x 588 bytes for 14ch and only 1x 624 bytes for 16ch (1x 780 bytes for 20ch) suggests as if the plan was for 2x 624 and 2x 780 but a minor bug creeped into the firmware, making the 16ch and 20ch modes limited by samplerate.

A quirk for linux UAC2 driver which rewrites the reported wMaxPacketSize to 2x 624 bytes  and 2x 780 bytes can test the device as is, without any firmware change.

With regards,

Pavel.

4 Reply by MC

  • MC
  • MC
  • Administrator
  • Offline
  • From: Germany/Thailand
  • Registered: 2007-04-06
  • Posts: 24,818

Re: UCX II USB configuration issue for 20ch and 16ch wMaxPacketSize?

The limitations are caused by external circuits - iOS does not support High Bandwidth mode, so 1 x packet modes are for that platform. 2 x packet is possible on Mac OS, Linux etc.

Note that CC mode is not for Windows and Mac - we do have drivers there, but the Mac is a wonderful CC test and debug tool. There everything works, the iPad also works. That is our goal. Just use what works, there is no error in the firmware.

Regards
Matthias Carstens
RME

MC's Website

5 Reply by MC

  • MC
  • MC
  • Administrator
  • Offline
  • From: Germany/Thailand
  • Registered: 2007-04-06
  • Posts: 24,818

Re: UCX II USB configuration issue for 20ch and 16ch wMaxPacketSize?

As an additional info on this subject: we just released a new firmware for the UCX II, that ups CC mode to version 19. This one now includes correct names for all I/O channels, plus fixes a small issue that prevented Windows to use the device in CC mode (not known to have affected anything else, though).

Regards
Matthias Carstens
RME

MC's Website

6 Reply by phofman (edited by phofman 2021-12-08 15:26:39)

  • Registered: 2021-11-21
  • Posts: 3

Re: UCX II USB configuration issue for 20ch and 16ch wMaxPacketSize?

A simple rudimentary patch to linux kernel sets the additional transaction bit to the wMaxPacketSize value reported by the card for 16ch and 20ch altsettings.

diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c
--- a/drivers/usb/core/config.c    (revision 018dd9dd80ab5f3bd988911b1f10255029ffa52d)
+++ b/drivers/usb/core/config.c    (date 1638972286064)
@@ -458,6 +458,26 @@
                 maxp);
     }
 
+    u16 vid = le16_to_cpu(udev->descriptor.idVendor);
+    u16 pid = le16_to_cpu(udev->descriptor.idProduct);
+
+    if (vid == 0x2a39 && pid == 0x3fd9) {
+        dev_info(ddev, "Detected USB device ID 0x%X:0x%X\n",
+            vid, pid);
+        if (udev->speed == USB_SPEED_HIGH && usb_endpoint_is_isoc_out(d)) {
+            dev_info(ddev, "Checking HS ISOC OUT EP\n");
+            if (maxp == 0x030c || maxp == 0x0270) {
+                unsigned int new_maxp;
+                // setting additional transaction packet (bit 11)
+                new_maxp = maxp | BIT(11);
+                dev_info(ddev, "Changing wMaxPacketSize from 0x%X to 0x%X\n",
+                    maxp, new_maxp);
+                endpoint->desc.wMaxPacketSize = cpu_to_le16(new_maxp);
+            }
+        }
+    }
+
+
     /* Parse a possible SuperSpeed endpoint companion descriptor */
     if (udev->speed >= USB_SPEED_SUPER)
         usb_parse_ss_endpoint_companion(ddev, cfgno,

The patched linux host now reports the internally modified wMaxPacketSize for 16ch and 20ch altsettings :

[  345.121561] usb 1-1.3: new high-speed USB device number 5 using xhci_hcd
[  345.221985] usb 1-1.3: config 1 has 4 interfaces, different from the descriptor's value: 5
[  345.222020] usb 1-1.3: Detected USB device ID 0x2A39:0x3FD9
[  345.222036] usb 1-1.3: Checking HS ISOC OUT EP
[  345.222049] usb 1-1.3: Changing wMaxPacketSize from 0x30C to 0xB0C
[  345.222064] usb 1-1.3: Detected USB device ID 0x2A39:0x3FD9
[  345.222079] usb 1-1.3: Detected USB device ID 0x2A39:0x3FD9
[  345.222092] usb 1-1.3: Checking HS ISOC OUT EP
[  345.222103] usb 1-1.3: Changing wMaxPacketSize from 0x270 to 0xA70
[  345.222117] usb 1-1.3: Detected USB device ID 0x2A39:0x3FD9
[  345.222134] usb 1-1.3: Detected USB device ID 0x2A39:0x3FD9
[  345.222147] usb 1-1.3: Checking HS ISOC OUT EP
[  345.222158] usb 1-1.3: Detected USB device ID 0x2A39:0x3FD9
[  345.222172] usb 1-1.3: Detected USB device ID 0x2A39:0x3FD9
[  345.222185] usb 1-1.3: Checking HS ISOC OUT EP
[  345.222196] usb 1-1.3: Detected USB device ID 0x2A39:0x3FD9
[  345.222210] usb 1-1.3: Detected USB device ID 0x2A39:0x3FD9
[  345.222224] usb 1-1.3: Detected USB device ID 0x2A39:0x3FD9
[  345.222238] usb 1-1.3: Detected USB device ID 0x2A39:0x3FD9
[  345.222252] usb 1-1.3: Detected USB device ID 0x2A39:0x3FD9
[  345.222267] usb 1-1.3: Detected USB device ID 0x2A39:0x3FD9
[  345.222281] usb 1-1.3: Detected USB device ID 0x2A39:0x3FD9
[  345.222748] usb 1-1.3: New USB device found, idVendor=2a39, idProduct=3fd9, bcdDevice= 3.01
[  345.222769] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  345.222784] usb 1-1.3: Product: Fireface UCX II (24066911)
[  345.222797] usb 1-1.3: Manufacturer: RME

Alsa plays correctly 16 and 20 channels to the card, clear undistorted tone on analog outputs confirmed:

pi@raspberrypi:~ $ sox -V -c 1 -r 192k -n -b 24 -c 20 -r 192k -t alsa hw:II24066911 synth 10000 sine 911 gain -6
sox:      SoX v14.4.2

Input File     : '' (null)
Channels       : 1
Sample Rate    : 192000
Precision      : 32-bit


Output File    : 'hw:II24066911' (alsa)
Channels       : 20
Sample Rate    : 192000
Precision      : 24-bit
Sample Encoding: 24-bit Signed Integer PCM
Endian Type    : little
Reverse Nibbles: no
Reverse Bits   : no

sox INFO sox: effects chain: input       192000Hz  1 channels
sox INFO sox: effects chain: synth       192000Hz  1 channels
sox INFO sox: effects chain: gain        192000Hz  1 channels
sox INFO sox: effects chain: channels    192000Hz 20 channels
sox INFO sox: effects chain: output      192000Hz 20 channels
In:0.00% 00:01:42.83 [00:00:00.00] Out:19.7M [ =====|===== ]        Clip:0


I do not have the card available for testing anymore. Should some card owner want to test and explore the options under linux more, let me know, I can provide compressed 32GB SD image for RPi4 (3GB download) with the kernel pre-compiled, or the kernel can be re-compiled on any machine locally.

The linux USB core already contains quirks for a number of devices. The developers would likely accept a well argumented patch, allowing to transfer all 16/20 channels to the device at 192kHz under linux, provided future firmware updates do not close this option somehow.