[alsa-devel] USB Driver Development Sinn 7 Status 24|96 (0x200c:0x1006)

[Marc Streckfuß]

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ß