EDIROL UA-1000 driver module

Hello,

   First message and although I've searching for this I don't believe
this topic has been proposed. I'm writing to ask for a (I believe)
small modification on snd-ua101.

The driver handles audio on the EDIROL UA-1000 perfectly (which is
amazing, thank you), but MIDI control of the device doesn't work at
all, and I think I've found why: the UA-1000 wants its control messages
on USB-MIDI cable 1, while the driver hardcodes cable 0.

Here's what I found:

The UA-1000 (USB 0582:0044) is a 10x10 USB 2.0 interface from 2003.
Besides audio it has a built-in digital mixer, a patch bay/router and
direct monitoring, all driven by Roland SysEx (DT1) messages over its
USB-MIDI interface — on Windows that's what the "UA-1000 Control Panel"
talks to. None of it is reachable from Linux today.

The device has 4 USB interfaces:
 - Interface 0: Control/mixer descriptors (no endpoints)
 - Interface 1: Audio capture (isochronous, EP 1 IN)
 - Interface 2: Audio playback (isochronous, EP 2 OUT)
 - Interface 3: MIDI control (bulk, EP 4 OUT + EP 3 IN)


The driver defines a fixed MIDI endpoint configuration:

   static const struct snd_usb_midi_endpoint_info midi_ep = {
       .out_cables = 0x0001,
       .in_cables  = 0x0001
   };

This configures MIDI on cable 0 (bit 0 set). However, the UA-1000
requires cable 1. I discovered this by capturing USB traffic from the
Windows XP driver using Wireshark/USBPcap while operating the official
EDIROL UA-1000 Control Panel software in a VirtualBox VM with USB
passthrough.

All SysEx messages captured from the Windows driver use USB-MIDI cable
1.
The cable number is encoded in the high nibble of each 4-byte USB-MIDI
packet's first byte (Code Index Number byte).

Here's an example, a captured Monitor Output Link On command:

   Raw USB-MIDI data (hex):
   14 f0 41 10  14 00 69 12  14 00 03 00  14 01 01 7b  15 f7 00 00

   Decoded packet-by-packet:

   Byte  Meaning
   ----  -------
   14    Cable 1 (high nibble = 0x1) | CIN 0x4 (SysEx start/continue)
   f0    SysEx start
   41    Roland manufacturer ID
   10    Device ID (default 0x10)

   14    Cable 1 | CIN 0x4
   00    Model ID byte 1
   69    Model ID byte 2 (0x00 0x69 = UA-1000)
   12    Command: DT1 (Data Set 1 = write)

   14    Cable 1 | CIN 0x4
   00    Address byte 1
   03    Address byte 2 (Monitor Output section)
   00    Address byte 3 (Left channel)

   14    Cable 1 | CIN 0x4
   01    Address byte 4 (Link parameter)
   01    Data (0x01 = on)
   7b    Roland checksum

   15    Cable 1 (high nibble = 0x1) | CIN 0x5 (SysEx ends with 1 byte)
   f7    SysEx end
   00    Padding
   00    Padding
   
If the device used cable 0, the high nibble of each packet would be
0x0_. All 18 capture files I have collected (input channel gain, pan,
solo, link, on/off, monitor output gain, monitor link, direct monitor
toggle, software control, and output volume mode) consistently show
cable 1.

I verified the fix by binary-patching the compiled snd-ua101.ko module.
At the offset where the midi_ep struct is stored, I changed:

   out_cables: 0x0001 -> 0x0002  (cable 0 -> cable 1)
   in_cables:  0x0001 -> 0x0002  (cable 0 -> cable 1)

   Before: 00 00 00 00 01 00 01 00
   After:  00 00 00 00 02 00 02 00

After loading the patched module, all SysEx commands are accepted by
the device. I have built a command-line control tool (ua1000ctl) that
successfully controls the UA-1000's mixer parameters via ALSA rawmidi,
including:

 - Monitor output volume (left, right, linked) — confirmed working
 - Monitor link on/off — confirmed working
 - Direct monitor on/off — confirmed working
 - Input channel on/off, solo, link, pan, and gain — addresses
identified

Audio capture and playback continue to work correctly with the patched
module and the MIDI port remains functional at hw:X,0,0 (subdevice 0).

I have 18 USB capture files covering all major SysEx command categories
and would be happy to share them if valuable.

To be transparent, I have relied heavily on Claude Code to help me in
several tasks I don't have the proper knowledge to do (and probably
would have not been able to implement). I have personally verified each
finding against the device but would like to be honest about it. I used
it for instance to analyze the USB captures, to inspect the device and
to modify a copy of the kernel module. 

If it is still a possibility to ask for an update (or patch) of the
module, it would be amazing though.

Thank you.