The thing that puzzles me is that the iJack strings are missing from
the output of libusb -v, which AFAIU is 100% independent of any ALSA
code whatsoever. This makes me suspect that no ALSA code is involved
in this regression. I've also determined since my email that some
other devices (e.g. an Ableton Push 2) do have iJack name data with
the 6.x kernel.
However, things got curiouser as I was trying to get the output of
alsa-info. It seems that under some conditions, the iJack strings for
the problematic device are available/displayed with lsusb. My initial
run of alsa-info showed the iJack strings, subsequent runs of
alsa-info and/or lsusb -v do not. I also see a continuous stream of
USB device resets (though these are not happening directly after being
connected and do not seem related to the presence/absence of iJack
strings).
So my guess is that is a highly device-specific problem and not a
regression in any part of the kernel.
On Mon, Oct 14, 2024 at 1:42 AM Takashi Iwai <tiwai@xxxxxxx> wrote:
>
> On Mon, 14 Oct 2024 09:36:35 +0200,
> Takashi Iwai wrote:
> >
> > On Sun, 13 Oct 2024 18:56:57 +0200,
> > Paul Davis wrote:
> > >
> > > I don't know where to start with this issue, but since I noticed it
> > > trying to use a MIDI device, I thought I would start here. Advice on
> > > where to take it would be much appreciated.
> > >
> > > High Level symptoms:
> > >
> > > 1. plugin in a Novation Lanchkey mk4 to (a) a system running kernel
> > > 6.x (b) a system running kernel 5.x
> > > 2. run aplaymidi -l or arecordmidi -l
> > >
> > > Results:
> > > (a) kernel 6.x: note the presence of two identical MIDI port
> > > names for the device
> > > (b) kernel 5.x: note the presence of two differently named MIDI
> > > ports for the device
> > >
> > > Mid-level diagnosis:
> > >
> > > Run lsusb -v on both kernels. For 5.x, note that the iJACK displays
> > > include a string for the MIDI port name. For 6.x note that this string
> > > is missing.
> > >
> > > Working with devices bearing identical ports for multiple names ranges
> > > from extremely difficult to impossible.
> > >
> > > I have no idea what layer of the stack can be involved here, other
> > > than that it is not hardware. I've run both 5.x and 6.x kernels on the
> > > same system.
> >
> > Could you try to narrow down the regression range, e.g. by testing
> > different 5.x and 6.x kernels? The best would be git-bisect, but
> > figuring out the first broken kernel version would help a lot
> > already.
> >
> > Also the issue can be very specific to the device, so please give the
> > details of your device. e.g. the alsa-info.sh outputs from both cases
> > as well as lsusb -v outputs.
>
> And, if it's about iJack handling for MIDI v1.x, the only recent
> change I can see is the upstream commit
> 41c25e193b2befc22462aa41591d397fab174ca1
> ALSA: usb-audio: More relaxed check of MIDI jack names
>
> You can try to revert it.
>
>
> Takashi
[Index of Archives]
[Pulseaudio]
[Linux Audio Users]
[ALSA Devel]
[Fedora Desktop]
[Fedora SELinux]
[Big List of Linux Books]
[Yosemite News]
[KDE Users]