[Beta Program] [Firmware] linux / mac inconsistency?

[thetechnobear]

so Ive just been hosting the midihub on the Organelle (arch linux) rPI (raspbian latest) and found an oddity

on alsa we see

aconnect -l 
client 28: 'midihub MH-2BXG0QD' [type=kernel]
    0 'midihub MH-2BXG0QD MIDI 1'
    1 'midihub MH-2BXG0QD MIDI 2'
    2 'midihub MH-2BXG0QD MIDI 3'
    3 'midihub MH-2BXG0QD MIDI 4'
    4 'midihub MH-2BXG0QD MIDI 5'

amidi -l 
IO  hw:0,0,0  midihub MH-2BXG0QD MIDI 1
IO  hw:0,0,1  midihub MH-2BXG0QD MIDI 2
IO  hw:0,0,2  midihub MH-2BXG0QD MIDI 3
IO  hw:0,0,3  midihub MH-2BXG0QD MIDI 4
IO  hw:0,0,4  midihub MH-2BXG0QD MIDI 5
IO  hw:1,0,0  Ableton Push 2 MIDI 1
IO  hw:1,0,1  Ableton Push 2 MIDI 2
IO  hw:2,0    pisound MIDI PS-3TG77SW

the issue is, 28:0 MIDI 1 is actually whats called port 5 on the mac , i.e. the control port
and so port 1 on the mac is MIDI 2 on the Organelle/rpi

(or if you wish hw:0,0,1 midihub MH-2BXG0QD MIDI 2, actually is USB A !)

it confused me quite a bit, as wasn’t getting any data , and theres no indicator of usb activity
(see previous issue )

ideally, hw:0,0,0 should be port 1 (USB A), and so the control port would be on hw:0,0,4

this is because quite a bit of software defaults to the first port, and some ‘dodgy’ software don’t even cope with usb subports, and just assume first port !
(not your issue, but if you want high compatibility its worth being aware of)

also perhaps in the usb description , you could label ‘port 5’ as CONTROL.
perhaps also it would be better to have the ports labelled A-D as well, given the case and editor labelling.
so
midihub MH-2BXG0QD MIDI A
midihub MH-2BXG0QD MIDI B
midihub MH-2BXG0QD MIDI C
midihub MH-2BXG0QD MIDI D
midihub MH-2BXG0QD CONTROL

(similar to ableton push which labels them LIVE, and the other USER)

note: i recognise some os/software does not use the usb description, but thats their problem

[Giedrius]

Unfortunately none of the 3 major OSes use the strings assigned to individual JACK descriptors in USB descriptor, so we can’t customize the numbering or wording there, as it takes it from the strings which apply to the device as a whole. (writing custom drivers for every OS would also be a pretty huge task, so we have to do our best to stick to what class USB MIDI drivers support of the different OSes)

To be honest, all of the OSes have bugs or short comings in their MIDI implementations, especially in cases where there’s more than one USB Endpoint being used. Surprisingly, only the Windows driver copes well with multiple endpoint MIDI device, and such devices are definitely allowed by the USB MIDI specification.

Originally, for handling high loads of data, I had Midihub have 4 I/O endpoints - 1 for every USB MIDI port, and 1 EP for editor communication. It worked really well on Windows, it treated every one of them asynchronously. Then I found the Linux limitation - its driver works with maximum of 2 MIDI endpoints per USB device (compile time configured value if I remember right, but still out of scope for us to provide custom kernels for Linux Desktops :))… So then I merged all user MIDI ports to one endpoint, and used the second endpoint for asynchronous Editor communication. Then MAC entered with its own issue - in such configuration, MAC instead of seeing 5 ports, only showed 1 I/O port, the editor’s. So then I tried placing the Editor’s EP first in the USB descriptor, then the one working with user MIDI ports, MAC started showing all of the 5 ports (only caveat is that it keeps using the 1st EP for Editor’s port with an out of bound virtual cable number…), the ordering on Linux then became as you describe, and only Windows driver was able even in this configuration, to respect the actual Jack ID numberings in the order of its MIDI devices.

For working with MAC, I do have a workaround which detects the MAC specific issue where it tries to access an out of bound virtual cable in the first EP, and then I switch to ‘MAC mode’ of operation where it presents that illegal port as the editor communication port, and still continues to work, using only a single EP for everything.

The downside of using a single EP for Midihub is that in case user would do a big sysex dump via Midihub’s USB port, the OS may delay sending Editor’s commands to Midihub, causing a timeout / disconnect from the device in contrast to using multiple endpoints asynchronously.

In the end, Midihub is still able to handle full load of sysex dumps through every port at the same time, on Mac the editor may lose connection during this period.

So this is the story how Linux ended up with such hardware port numbering.

To get the ideal ordering, which I would prefer myself too, we would have to get rid of the 2nd EP, dedicated for async communication with the Editor, but that would also open up Linux and Windows implementations to get disconnects during maximum load (which may be rare enough for us not to worry about)

I think it makes sense to run this experiment of working only via the single EP for everything on every OS during the beta and see whether we get any issue reports caused by this.

[thetechnobear]

ouch, sounds like a bit of a pain!
(typical story of cross platform development unfortunately, finding a compromises that work)

@Giedrius

In the end, Midihub is still able to handle full load of sysex dumps through every port at the same time, on Mac the editor may lose connection during this period.

yeah, thats probably not a big issue , as you know your sending a large amount of data …
I think key is that the user knows its just the editor disconnecting, and that everything on the hub (and his sysex dump in particular) is all still working correctly.
so, I guess, phrasing the ‘disconnect’ error message appropriately, or including something in the help text will help users know why it disconnected.