something went wrong with USB iJack data in kernel 6.x

something went wrong with USB iJack data in kernel 6.x

[Paul Davis]

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.

Re: something went wrong with USB iJack data in kernel 6.x

[Takashi Iwai]

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. 


thanks,

Takashi

Re: something went wrong with USB iJack data in kernel 6.x

[Takashi Iwai]

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

Re: something went wrong with USB iJack data in kernel 6.x

[Paul Davis]

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@suse.de> 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

Re: something went wrong with USB iJack data in kernel 6.x

[Takashi Iwai]

On Mon, 14 Oct 2024 18:03:40 +0200,
Paul Davis wrote:
> 
> 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.

Yes, it smells more like a firmware bug of the device.

If you prefer having some static names, you can define the entries in
snd_usbmidi_port_info[] in sound/usb/midi.c for each corresponding
MIDI port, too.


Takashi

> 
> 
> On Mon, Oct 14, 2024 at 1:42 AM Takashi Iwai <tiwai@suse.de> 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