Ubuntu/Chrome connection problem

yes, it’s still a lot of work and waiting time for compiles, reboots etc… but probably the best thing to do to get closer to the problem - I too suspect some changes around the midi 2.0 addition…

I also wanted to look deeper into the things you wrote above about shell commands that show occurences of the problem outside the browser.

It’s not that difficult to find these kernel developers who probably will care - it’s not many people who work on the alsa and midi things… at least I hope they will care once I contacted them.

But usually it’s really important to have a way to show developers how to reproduce a problem because despite caring, developers can usually not do much about a problem that they are not able to reproduce.

But if I can’t create reproduction steps that everyone can go also without owning a specific hardware, the bisecting idea from @szszoke is the way to go.

Another thing I tried in the meantime was check behaviour of other distributions and their Kernel / Browser, as well as other applications that do midi and sysex stuff.

Starting with the latter, I found that that management software/editor for Blokas Midihub which is a native AppImage app doesn’t show any problems when running with the latest Ubuntu 23.10 kernel 6.5.x.

Then I installed and checked Fedora 39 which also has a 6.5.x Kernel and show the same nonworking behaviour with 6.5 Kernels, but works with Kernel Versions 6.1, 6.2 and 6.3 (manually downloaded from their kernel build repositories, packages originally intended for fc38) - But ONLY with Chromium Browser, and only with the version that I install via NixOS - the Chromium that I can install normally via Fedoras dnf package manager shows the same errors.

Accidentally I found out that in Fedora 38 it works, even when I run it as a virtual machine inside fedora 39 via gnome-boxes where I can chose to hand over USB device to the VM guest OS.

So, currently it looks that

  • with kernels from 6.5.x and above it never works
  • the problem currently only has been seen with sysex stuff via Web Browsers/ Web Midi, not when midi/sysex stuff is done outside a browser
  • even with earlier Kernels then 6.5 the problem still occurs with some browsers. While it is known (or at least my experience) that any browser installed via snap doesn’t work because of permission and access issues, also not all all non-snap installed browsers work. Browser it seems to always work with is chromium when installed via NixOS package manager.

also thanks for confirming the Ubuntu bug.

Can you also confirm that things work for you as soon as you downgrade your kernel?

I’m sorry but this is my work PC as well, I’m not especially good or inclined with command-line etc, and I don’t feel like downgrading for the E1 testing. It does what I need it to do now… Again, I’m sorry for being such a bad tester. :confused:

I could have guided you through that installation - it’s not a full OS downgrade or something, it’s just a manual instalation of packages with older Kernels while the standard Kernel can be kept and also can keep being the default.
But if you are worried about your work machine it’s completely understandable that you don’t want to mess it up!

But I am surprised you say you have a working setup now.
How did you get there and which combination of OS / Kernel / Browser works for you? Or do you mean you are simply using WIndows now for the things that dont work with Linux?

My Ubuntu upgrade from 23.04 to 23.10 went wrong for [reasons unrelated to the E1] and I ended up with a fresh install.

Yes, I reinstalled DrivenByMoss with Windows, it works now, and I don’t need to touch it until this preset or the E1 need an upgrade.

As far as I know, the Midihub is using a USB serial port for configuration and not MIDI.

1 Like