All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Paul Davis <paul@linuxaudiosystems.com>
Cc: Takashi Iwai <tiwai@suse.de>, linux-sound@vger.kernel.org
Subject: Re: something went wrong with USB iJack data in kernel 6.x
Date: Tue, 15 Oct 2024 16:39:49 +0200	[thread overview]
Message-ID: <87wmi9top6.wl-tiwai@suse.de> (raw)
In-Reply-To: <CAFa_cKmS-DHykwA=Ej1w9i3+yfz4wyPJTtEG9ADNTJ8t2GSBQw@mail.gmail.com>

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

      reply	other threads:[~2024-10-15 14:38 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-13 16:56 something went wrong with USB iJack data in kernel 6.x Paul Davis
2024-10-14  7:36 ` Takashi Iwai
2024-10-14  7:43   ` Takashi Iwai
2024-10-14 16:03     ` Paul Davis
2024-10-15 14:39       ` Takashi Iwai [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wmi9top6.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=linux-sound@vger.kernel.org \
    --cc=paul@linuxaudiosystems.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.