Hello Guys, I apologize in advance if this is the wrong mailing list (In general I am new to Mailing Lists), but I thought since I plan to develop a driver this might fit, I'm just not completely done.

== Device Information The Device in Question is from the Brand "Sinn 7" with the name "Status 24|96", it's a relatively unknown recording interface design to be used in DAWs on Windows using Steinberg's Proprietary ASIO Interface. This is to provide a low-latency interface on Windows but it seems to be support a regular interface as well (at least you can use it as regular windows speaker and have different options there).

It seems to be manufactured by Reloop, since that's the vendorId 0x200c. I tried the snd-usb-audio quirk for the Reloop Play already, but it didn't work (Applying the Quirk seemed to fail, due to endpoint mismatch, etc).

From reverse engineering the windows driver a bit I found the name "

usb-audio.de". It's a website of the Pylotec GmbH which seems to provide the base boards for USB Audio Hardware used in many Interfaces (They have a page where they mention what is using their usb audio driver)

The interesting lsusb output is this (I omitted the "empty" altsetting 0 for both interfaces, all classes are 0xFF == Vendor Specific): Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 1 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x0004 1x 4 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x05 EP 5 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x86 EP 6 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1

== My Findings So after days of trying out different quirks, building my own version of the snd-usb-audio and endless research I found out some stuff. A) I have captured the init sequence and I am able to redo it using libusb B) It turns out that there are 3 permanent communication types, even when I disable the device in Windows: There are writes to the Isochronous Endpoint 0x2 containing 32 Sub-Packets, so that is 128 Bytes of 0x0. Oddly enough that isn't the Audio data!! There are writes to the Bulk Endpoint 0x5 containing a variable size ranging roughly from ~16kB to 20kB. These are filled mostly with 0x0, but periodically (every 200h Bytes?) I had a 0xFD 0xFF Sequence. Those actually contain the Audio Data. I was able to produce some knocking sound when sending random values (either 0x0 or 0x1!) here. [I was expecting a white noise, though] => This is where I am stuck. I understand the idea of PCM in General, but I would expect it to send [0, 0xFF] values and not just 0x0 or 0x1, since that is a bandwidth waste. This and I would also expect a constant packet size. If it is variable, does that mean that the Sample Rate changes? (Note: I confirmed the 0x0..0x1 and the variable packet size both: By using libusb/pyUSB and by sniffing the traffic of a virtual windows box with Wireshark) There are reads from the Bulk Endpoint 0x86 (Note: Different InterfaceNumber, but it seems to work without changing the interface??) which result in an array of values ranging from 0x0 to 0x3. (Maybe that would apply to the output as well and during sniffing I just had the test sound too low gained?). Most of the time their size seems to be in line with the output bulk packets.

Some of the sent sizes (data fields only) are: 19'986Bytes, 16'384 Bytes, 12'800 Bytes however most of the time it's 16k, whereas the output tends to go to 19k and the input to 12k (I have nothing attached to the input connectors).

Now what I actually want to know: Does that protocol sound familiar to you? Do you have a clue on how to patch it in as a simple quirk? I was thinking maybe I can use a setup quirk and then let the FIXED_ENDPOINT do the rest? However I am stuck with the Format, I don't know whether that really is a known format or if I need some conversion and how it is with some synchronization clock and such.

Basically I need information on how to proceed.

- Marc Streckfuß