Alsa Midi port name ambiguity trouble

[Impostor]

@Linuxmusician01 and @j_e_f_f_g

Port 0 is used for the usual stuff (keynotes, pitch bend, program change etc), and Port 1 (as I later found out) seems to be only to send commands from the transport buttons (likely for DAWs which have two Midi in ports: Ableton Lite was bundled with the keyboard).
My guess is that MusE gets exposed to Port 1 first, and then because Port 0 is later exposed with the same name, it gets ignored somehow. (Or the other way around, and the latest 'overwrites' the first.) That is consistent with the fact that routing both ports via midi through does result in signals from both ports being recognized in MusE.

I don't exactly know what kind of bug/feature this represents: a bug in Alsa with naming the ports, or one in QJackctl and MusE by using only the name and not the port numbers?Both? Neither?

[Linuxmusician01]

[...]
I don't exactly know what kind of bug/feature this represents: a bug in Alsa with naming the ports, or one in QJackctl and MusE by using only the name and not the port numbers?Both? Neither?

Like @j_e_f_f_g said: it might be a hardware quirk, not a bug from Linux.

[Impostor]

[...]
I don't exactly know what kind of bug/feature this represents: a bug in Alsa with naming the ports, or one in QJackctl and MusE by using only the name and not the port numbers?Both? Neither?

Like @j_e_f_f_g said: it might be a hardware quirk, not a bug from Linux. :)

But if it were a hardware quirk, why does it only show up when I boot with newer kernels? With kernels 5.4, 5.8 and 5.11 all worked as it should.

[Linuxmusician01]

[...]
I don't exactly know what kind of bug/feature this represents: a bug in Alsa with naming the ports, or one in QJackctl and MusE by using only the name and not the port numbers?Both? Neither?

Like @j_e_f_f_g said: it might be a hardware quirk, not a bug from Linux.

But if it were a hardware quirk, why does it only show up when I boot with newer kernels? With kernels 5.4, 5.8 and 5.11 all worked as it should.

Good question. I guess it's like @j_e_f_f_g said: the newer kernels don't handle that quirk anymore...

[Impostor]

Good question. I guess it's like @j_e_f_f_g said: the newer kernels don't handle that quirk anymore...

But look at the devices setting in Pianoteq. Even though both Keystation ports are assigned the same name, Pianoteq still distinguishes the two ports correctly...

[Impostor]

I'm trying to make a clean argument here:

The observations:

-The naming by Alsa of the Keystation's two midi ports changed between kernels 5.11 and 5.13, as seen by running 'aconnect -i':

from
0:'Keystation 49 MK3 MIDI 1'
1:'Keystation 49 MK3 MIDI 2'

to
0:'Keystation 49 MK3 Keystation 49'
1:'Keystation 49 MK3 Keystation 49'

-Certain software, running on the newer kernel, doesn't recognize these two distinct ports anymore, whereas on older kernels they did:

==In QJackCtl 0.9.7 Patchbay, any connection can only be set for both ports together, not individually. While in the graph, distinct connections -can- still be made.
==And in MusE 4.1 Midi Devices, regardless of actual connections, only what turns out to be port 1 shows up, under the name "Keystation 49 MK3 Keystation 49".

-Other software, like Pianoteq 7.5.4, still recognizes the two distinct ports correctly. Also, Alsa Midi Through can still handle both ports just fine.


We can argue about whether it's a bug or a feature, but giving distinct midi ports (over the same usb cable or not) identical names is not necessarily a good thing, imo. And given the above observations, it's not too much of a stretch to postulate that this change in the naming of alsa midi ports is actually what causes the 'anomalous' behaviour of Midi devices in MusE and QJackCtl when running on the newer kernel.

And since both MusE and Pianoteq -should- produce the same list of Alsa Midi devices after scanning for them (or getting them presented by Alsa), while in fact they don't, corroborates my assumption that MusE somehow ignores device numbers, while Pianoteq does take them into account.

Anyway, I really doubt it is a hardware quirk. Not impossible, but unlikely:)

I'll let the topic rest for now. It's not a game breaking bug anyway (yet!).

[j_e_f_f_g]

It's likely not a bug in Linux itself. It's most likely an incompatibility between PulseAudio's way of naming MIDI devices versus PipeWire's PulseAudio emulation. (If you're using Debian Sid, I'm pretty sure you're now using Pipewire's PulseAudio and Jack emulations instead of the real items). I'll bet that if you uninstall PipeWire, and install PulseAudio and Jack, things will revert to the old behavior.

That's how I fixed a MIDI problem I encountered after upgrading Debian Testing. I figured out that every program that used PA or JACK suddenly was not letting go of the soundcard, whereas before this wasn't an issue. Turns out pipewire's 'device allocation' isn't 100% compatible with pa/jack.

Fortunately, muse has the option to bypass unneeded shit like pa/jack (and emulations like pipewire), and use alsa directly. Run it with the -A (i think) command line option to use alsa midi. That should bypass this pipewire problem.... for muse.

[Impostor]

I'll bet that if you uninstall PipeWire, and install PulseAudio and Jack, things will revert to the old behavior.

I actually run Linux Mint, with Pulseaudio and Jack. And I run the appimage of MusE, so running it with command line options is probably not an option, but I'll try something..

EDIT: I started MusE with no audio backend, just MIDI, and this gives the exact same issue as before. Only Port 1 is available under the name "Keystation 49 MK3 Keystation 49" .

[j_e_f_f_g]

oh wait. You tested with aconnect. This new behavior is indeed due to a change in alsa's naming convention. Your theory is likely correct. See if muse can use alsa rawmidi instead of SEQ API.. Maybe muse will then show both midi in's as separate devices.

[Impostor]

oh wait. You tested with aconnect. This new behavior is indeed due to a change in alsa's naming convention. Your theory is likely correct. See if muse can use alsa rawmidi instead of SEQ API.. Maybe muse will then show both midi in's as separate devices.

Finally some progress:

Setting midi protocol to RAW instead of SEQ in QJackCtl still results in a single device (Keystation 49 MK3 Keystation 49) showing up in the MIDI Devices tab of MusE, but instead of "STATE=OK" it gives "STATE=Play, Resource temporarily unavailable". Yet now -all- midi events from the keyboard are indeed registered, both those of port 0 and port 1!

EDIT: Sorry, midi through was still connected. No it did not work. Still only signals from port 1! And in the Patchbay of QJackCtl there's still two plugs of the same name under the MK3 'socket', one of which still disappears when selecting the other...

[j_e_f_f_g]

two plugs of the same name under the MK3 'socket', one of which still disappears when selecting the other...

No doubt this change in alsa's device naming was done to give more descriptive names to endusers. If the keystation had a dedicated alsa midi driver (instead of using the generic USB-MIDI alsa driver), it could report the two midi ports with names such as "Keystation 49 piano keyboard" and "Keystation 49 transport buttons". That's a lot more informative than "MIDI 1" and "MIDI 2".

But, it appears to use the generic USB-MIDI alsa driver, which no doubt is getting those "descriptive names" by querying the "endpoint names" from the USB controller chip inside the keystation 49. And unfortunately, that chip is giving the same name to both endpoints. (It shouldn't. The chip maker probably cut some corners with onboard logic to reduce cost, with the result that endpoints all share one name. That chip maker obviously does not expect the OS to use those names as "labels" presented to endusers. But it would have been very good if the maker had designed it with this useful feature, instead of saving pennies. Unrestricted capitalism sucks).

You need to get ahold of the alsa devs, and let them know that this new behavior is a problem. They have two possible solutions:

1) Do a strcmp() on the endpoint names, and if two or more are the same string, revert to using the old convention of simply naming the midi ins and outs numerically. (ie Go back to names like "MIDI In 1", MIDI In 2", MIDI In 3", etc).

2) Add a "quirk rule" to the USB-MIDI driver that, when it detects the keystation 49's USB "model ID", automatically gives the first USB MIDI endpoint a name like "Keystation 49 piano keyboard", and the second endpoint a name like "Keystation 49 transport buttons".

And you then need to get ahold of the muse devs, and tell them that saving only the device "string name", without the device and subdevice numbers, is really bad because it's susceptible to breaking in the exact way kernel 5.11 just did it. If they want to see a reliable way to save/restore device configuration for ALSA Seq API as well as rawmidi devices, tell them to see how I do it in BackupBand, which supports both midi apis, and uses a combo of both names and device/subdevice "id" to save/load configuration.

In fact, you can post the above text verbatim on pertinent fotums/mail-lists.

[Linuxmusician01]

oh wait. You tested with aconnect. This new behavior is indeed due to a change in alsa's naming convention. Your theory is likely correct. See if muse can use alsa rawmidi instead of SEQ API.. Maybe muse will then show both midi in's as separate devices.

That's interesting information. Why do the Alsa dev's fix something that ain't broken? This is why I fear and loathe updating (any OS or software). I visited the support website for the M-Audio Keystation 49 Mk. 3 and there aren't even drivers for Windows. That says a lot. It means that the keyboard is class compliant, the Alsa devs are the problem here! What a SnAFU.

[j_e_f_f_g]

Why do the Alsa dev's fix something that ain't broken?

What they're obviously trying to do is provide the endusers more descriptive names for devices. So, instead of names like "Audio channel 1+2", "Audio channel 3+4", "MIDI In 1", "MIDI In 2", etc, you instead have names like "Main Audio Mix Out", "Headphone Mix Out", "MIDI Keyboard", "MIDI Transport Control", etc.

This is a good thing.

But, the only ways to get these descriptive labels is either:

1) Require a dedicated audio driver (which supplies the descriptive labels) for every audio/MIDI interface on the market. This is pretty much how MacOS and WIndows do it. They put the onus on the hardware manufacturers to supply that info (in dedicated drivers). And the manufacturers have to do it if they want to sell to macos/Win customers.

2) Try to get the descriptive names from the hardware by using generic protocols. For example, USB protocol allows a USB controller chip to assign a name to every USB "endpoint" (ie, audio channel, MIDI In or Out port, etc). So if the device is USB, the OS can try to get descriptive labels from the device's USB controller chip. This is how linux does it. Unfortunately, not all chip manufacturers are providing this info (because MacOS/Windows don't use it). Where the alsa devs have failed is not accounting for something stupid, like a chip that gives the same name to all its endpoints. They just need to fix that per one of my preceding post's "solutions".

It's a temporary oversight that I'm sure will be quickly fixed (once someone makes the alsa devs aware of it).

I have no problem with situations like this. The bug was introduced when the devs added code that has clear advantages. It's not a result of adding unnecessary nor poorly conceived code. Bugs happen. They can be fixed usually with minimal disruption.

What I hate with a passion is when devs come up with totally unnecessary code that ultimately makes things more difficult and prone to breaking. An example is creating yet another "audio server" that sits on top of alsa, does pretty much the same thing as every other unnecessary misguided mess that sits on top of alsa, and just adds yet more complexity/breakage to linux audio. For christ's sake, stop making that shit, people! When that crap worms its way into the ecosystem, it typically takes years of pain before we're rid of it.

for the M-Audio Keystation 49 Mk. 3 there aren't even drivers for Windows.

There's probably one 'maudio Windows usb midi' driver that supports their entire line of usb keyboards on Windows. This is how yamaha, casio, roland, etc do it.

[Impostor]

But, it appears to use the generic USB-MIDI alsa driver, which no doubt is getting those "descriptive names" by querying the "endpoint names" from the USB controller chip inside the keystation 49. And unfortunately, that chip is giving the same name to both endpoints.

Ha! So it's probably a combination of three factors: a hardware quirk, an alsa driver quirk, and a software-application quirk? Let's go see which of the three accepts this as a bug instead of a feature then! I won't bother with the keyboard manufacturer, but I'll see if I can drop a bug report for Alsa and MusE somewhere. Should I bother with QJackCtl? There's no need -for me- to ever connect these ports independently, but maybe the bug will show up for others who have hardware with multiple midi ports over a single usb cable too, or even two identical devices on different cables.

[j_e_f_f_g]

it's probably a combination of three factors

At this point, I'm confident "probably" = "almost certainly".

1) The keystation's USB controller gives the same name to all its endpoints, This is dumb. It should either give them different names, or not give them names at all.

2) Alsa's new code that gets descriptive names from USB controllers doesn't take the above aberation into account.

3) Muse relies on a device's "descriptive name" only for saving its configuration. Unlike BackupBand, it doesn't use a combo of names and device id numbers to conclusively pinpoint a device. Therefore, muse's configuration is susceptible to a change of the device name.

which of the three accepts this as a bug

Ideally, all 3 should. But in practical terms, your problem will be fixed with only the alsa bug being fixed. Once that happens, QJackCtl and Muse will work.

But Muse devs should still beef up their config save code, because it will still be susceptible to breaking.

two identical devices on different cables.

That's asking for headaches on any operating system.