Re: [alsa-devel] [PATCH] ALSA: usb-audio: Disable quirks for BOSS Katana amplifiers

Re: [alsa-devel] [PATCH] ALSA: usb-audio: Disable quirks for BOSS Katana amplifiers

[Takashi Iwai]

On Fri, 11 Oct 2019 19:19:36 +0200,
Szabolcs Szőke wrote:
> 
> BOSS Katana amplifiers cannot be used for recording or playback if quirks
> are applied
> 
> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=195223
> Signed-off-by: Szabolcs Szőke <szszoke.code@gmail.com>

Applied now.  Thanks.


Takashi

> 
> ---
>  sound/usb/pcm.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c
> index 33cd26763c0e..daadb0c66eee 100644
> --- a/sound/usb/pcm.c
> +++ b/sound/usb/pcm.c
> @@ -348,6 +348,9 @@ static int set_sync_ep_implicit_fb_quirk(struct snd_usb_substream *subs,
>  		ep = 0x84;
>  		ifnum = 0;
>  		goto add_sync_ep_from_ifnum;
> +	case USB_ID(0x0582, 0x01d8): /* BOSS Katana */
> +		/* BOSS Katana amplifiers do not need quirks */
> +		return 0;
>  	}
>  
>  	if (attr == USB_ENDPOINT_SYNC_ASYNC &&
> -- 
> 2.20.1
> 
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [alsa-devel] [PATCH] ALSA: usb-audio: Disable quirks for BOSS Katana amplifiers

[Szabolcs Szőke]

Thank you for your help!

Den tors 17 okt. 2019 10:19Takashi Iwai <tiwai@suse.de> skrev:

> On Fri, 11 Oct 2019 19:19:36 +0200,
> Szabolcs Szőke wrote:
> >
> > BOSS Katana amplifiers cannot be used for recording or playback if quirks
> > are applied
> >
> > BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=195223
> > Signed-off-by: Szabolcs Szőke <szszoke.code@gmail.com>
>
> Applied now.  Thanks.
>
>
> Takashi
>
> >
> > ---
> >  sound/usb/pcm.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c
> > index 33cd26763c0e..daadb0c66eee 100644
> > --- a/sound/usb/pcm.c
> > +++ b/sound/usb/pcm.c
> > @@ -348,6 +348,9 @@ static int set_sync_ep_implicit_fb_quirk(struct
> snd_usb_substream *subs,
> >               ep = 0x84;
> >               ifnum = 0;
> >               goto add_sync_ep_from_ifnum;
> > +     case USB_ID(0x0582, 0x01d8): /* BOSS Katana */
> > +             /* BOSS Katana amplifiers do not need quirks */
> > +             return 0;
> >       }
> >
> >       if (attr == USB_ENDPOINT_SYNC_ASYNC &&
> > --
> > 2.20.1
> >
>
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [alsa-devel] [PATCH] ALSA: usb-audio: Disable quirks for BOSS Katana amplifiers

[Mailing Lists]

Following up on this, it appears there are a bunch of the newer-generation
Roland/Boss devices which need similar treatment.

So far I have tested the GT-1, the GT-001, and the BR-80, and others have
reported the RC-300 as working with similar modifications. I have been
using the following change to the code in pcm.c
set_sync_ep_implicit_fb_quirk:

    case USB_ID(0x0582, 0x01d8): /* BOSS Katana */
    case USB_ID(0x0582, 0x0130): /* BOSS Micro BR-80 */
    case USB_ID(0x0582, 0x0138): /* BOSS RC-300 */
    case USB_ID(0x0582, 0x01d6): /* BOSS GT-1 */
    case USB_ID(0x0582, 0x01e5): /* BOSS GT-001 */
/* BOSS Katana amplifiers and many other newer BOSS devices do not need
quirks */

There's probably others too, such as the GT-100 (I believe the GT-001 and
GT-100 have similar hardware).

My question is, should this just be submitted as a patch to pcm.c or would
it be better handled in quirks and, if so, how?

Or something else?

Personally, I dislike the approach of hard-coding exceptions into core code
as it seems that's what quirks are there for, but there seems to be a whole
bunch of exceptions in there already.

Cheers,

Keith

On Thu, 17 Oct 2019 at 09:20, Takashi Iwai <tiwai@suse.de> wrote:

> On Fri, 11 Oct 2019 19:19:36 +0200,
> Szabolcs Szőke wrote:
> >
> > BOSS Katana amplifiers cannot be used for recording or playback if quirks
> > are applied
> >
> > BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=195223
> > Signed-off-by: Szabolcs Szőke <szszoke.code@gmail.com>
>
> Applied now.  Thanks.
>
>
> Takashi
>
> >
> > ---
> >  sound/usb/pcm.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c
> > index 33cd26763c0e..daadb0c66eee 100644
> > --- a/sound/usb/pcm.c
> > +++ b/sound/usb/pcm.c
> > @@ -348,6 +348,9 @@ static int set_sync_ep_implicit_fb_quirk(struct
> snd_usb_substream *subs,
> >               ep = 0x84;
> >               ifnum = 0;
> >               goto add_sync_ep_from_ifnum;
> > +     case USB_ID(0x0582, 0x01d8): /* BOSS Katana */
> > +             /* BOSS Katana amplifiers do not need quirks */
> > +             return 0;
> >       }
> >
> >       if (attr == USB_ENDPOINT_SYNC_ASYNC &&
> > --
> > 2.20.1
> >
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>


-- 
-- 
Keith A Milner

Re: [alsa-devel] [PATCH] ALSA: usb-audio: Disable quirks for BOSS Katana amplifiers

[Takashi Iwai]

On Wed, 14 Oct 2020 14:17:35 +0200,
Mailing Lists wrote:
> 
> Following up on this, it appears there are a bunch of the newer-generation
> Roland/Boss devices which need similar treatment.
> 
> So far I have tested the GT-1, the GT-001, and the BR-80, and others have
> reported the RC-300 as working with similar modifications. I have been using
> the following change to the code in pcm.c set_sync_ep_implicit_fb_quirk:
> 
>     case USB_ID(0x0582, 0x01d8): /* BOSS Katana */
>     case USB_ID(0x0582, 0x0130): /* BOSS Micro BR-80 */
>     case USB_ID(0x0582, 0x0138): /* BOSS RC-300 */
>     case USB_ID(0x0582, 0x01d6): /* BOSS GT-1 */
>     case USB_ID(0x0582, 0x01e5): /* BOSS GT-001 */
> /* BOSS Katana amplifiers and many other newer BOSS devices do not need quirks
> */
> 
> There's probably others too, such as the GT-100 (I believe the GT-001 and
> GT-100 have similar hardware).
> 
> My question is, should this just be submitted as a patch to pcm.c or would it
> be better handled in quirks and, if so, how?
> 
> Or something else?

Do we really need this change at all?  I looked at the code again, and
I noticed that basically the function should return 0 without setting
anything else even if you don't have the explicit ID checks there.

The function looks like:

static int set_sync_ep_implicit_fb_quirk(struct snd_usb_substream *subs,
					 struct usb_device *dev,
					 struct usb_interface_descriptor *altsd,
					 unsigned int attr)
{
	....
	switch (subs->stream->chip->usb_id) {
	....
	case USB_ID(0x0582, 0x01d8): /* BOSS Katana */
		/* BOSS Katana amplifiers do not need quirks */
		return 0;
	}

	if (attr == USB_ENDPOINT_SYNC_ASYNC &&
	    altsd->bInterfaceClass == USB_CLASS_VENDOR_SPEC &&
	    altsd->bInterfaceProtocol == 2 &&
	    altsd->bNumEndpoints == 1 &&
	    USB_ID_VENDOR(subs->stream->chip->usb_id) == 0x0582 /* Roland */ &&
	    search_roland_implicit_fb(dev, altsd->bInterfaceNumber + 1,
				      altsd->bAlternateSetting,
				      &alts, &ep) >= 0) {
		goto add_sync_ep;
	}

	/* No quirk */
	return 0;

... and the lengthy if-conditions after the switch/case is applied
only for Roland devices, hence it shouldn't influence on BOSS
devices.  After that point, the immediate return with 0, which is the
same as we do in switch/case.  So the explicit check of BOSS devices
there looks superfluous.


thanks,

Takashi

Re: [alsa-devel] [PATCH] ALSA: usb-audio: Disable quirks for BOSS Katana amplifiers

[Mailing Lists]

Thanks for the response Takashi,

How should this be distinguishing between Roland and BOSS? They both have
the vendor ID 0x0582.

Cheers,

Keith

On Wed, 14 Oct 2020 at 14:09, Takashi Iwai <tiwai@suse.de> wrote:

> On Wed, 14 Oct 2020 14:17:35 +0200,
> Mailing Lists wrote:
> >
> > Following up on this, it appears there are a bunch of the
> newer-generation
> > Roland/Boss devices which need similar treatment.
> >
> > So far I have tested the GT-1, the GT-001, and the BR-80, and others have
> > reported the RC-300 as working with similar modifications. I have been
> using
> > the following change to the code in pcm.c set_sync_ep_implicit_fb_quirk:
> >
> >     case USB_ID(0x0582, 0x01d8): /* BOSS Katana */
> >     case USB_ID(0x0582, 0x0130): /* BOSS Micro BR-80 */
> >     case USB_ID(0x0582, 0x0138): /* BOSS RC-300 */
> >     case USB_ID(0x0582, 0x01d6): /* BOSS GT-1 */
> >     case USB_ID(0x0582, 0x01e5): /* BOSS GT-001 */
> > /* BOSS Katana amplifiers and many other newer BOSS devices do not need
> quirks
> > */
> >
> > There's probably others too, such as the GT-100 (I believe the GT-001 and
> > GT-100 have similar hardware).
> >
> > My question is, should this just be submitted as a patch to pcm.c or
> would it
> > be better handled in quirks and, if so, how?
> >
> > Or something else?
>
> Do we really need this change at all?  I looked at the code again, and
> I noticed that basically the function should return 0 without setting
> anything else even if you don't have the explicit ID checks there.
>
> The function looks like:
>
> static int set_sync_ep_implicit_fb_quirk(struct snd_usb_substream *subs,
>                                          struct usb_device *dev,
>                                          struct usb_interface_descriptor
> *altsd,
>                                          unsigned int attr)
> {
>         ....
>         switch (subs->stream->chip->usb_id) {
>         ....
>         case USB_ID(0x0582, 0x01d8): /* BOSS Katana */
>                 /* BOSS Katana amplifiers do not need quirks */
>                 return 0;
>         }
>
>         if (attr == USB_ENDPOINT_SYNC_ASYNC &&
>             altsd->bInterfaceClass == USB_CLASS_VENDOR_SPEC &&
>             altsd->bInterfaceProtocol == 2 &&
>             altsd->bNumEndpoints == 1 &&
>             USB_ID_VENDOR(subs->stream->chip->usb_id) == 0x0582 /* Roland
> */ &&
>             search_roland_implicit_fb(dev, altsd->bInterfaceNumber + 1,
>                                       altsd->bAlternateSetting,
>                                       &alts, &ep) >= 0) {
>                 goto add_sync_ep;
>         }
>
>         /* No quirk */
>         return 0;
>
> ... and the lengthy if-conditions after the switch/case is applied
> only for Roland devices, hence it shouldn't influence on BOSS
> devices.  After that point, the immediate return with 0, which is the
> same as we do in switch/case.  So the explicit check of BOSS devices
> there looks superfluous.
>
>
> thanks,
>
> Takashi
>


-- 
-- 
Keith A Milner

Re: [alsa-devel] [PATCH] ALSA: usb-audio: Disable quirks for BOSS Katana amplifiers

[Takashi Iwai]

On Wed, 14 Oct 2020 15:33:03 +0200,
Mailing Lists wrote:
> 
> Thanks for the response Takashi,
> 
> How should this be distinguishing between Roland and BOSS? They both have the
> vendor ID 0x0582.

Ah, right, I missed that point :-<

So the question would be rather how to detect BOSS devices
effectively...


thanks,

Takashi

> 
> Cheers,
> 
> Keith
> 
> On Wed, 14 Oct 2020 at 14:09, Takashi Iwai <tiwai@suse.de> wrote:
> 
>     On Wed, 14 Oct 2020 14:17:35 +0200,
>     Mailing Lists wrote:
>     >
>     > Following up on this, it appears there are a bunch of the
>     newer-generation
>     > Roland/Boss devices which need similar treatment.
>     >
>     > So far I have tested the GT-1, the GT-001, and the BR-80, and others
>     have
>     > reported the RC-300 as working with similar modifications. I have been
>     using
>     > the following change to the code in pcm.c set_sync_ep_implicit_fb_quirk:
>     >
>     >     case USB_ID(0x0582, 0x01d8): /* BOSS Katana */
>     >     case USB_ID(0x0582, 0x0130): /* BOSS Micro BR-80 */
>     >     case USB_ID(0x0582, 0x0138): /* BOSS RC-300 */
>     >     case USB_ID(0x0582, 0x01d6): /* BOSS GT-1 */
>     >     case USB_ID(0x0582, 0x01e5): /* BOSS GT-001 */
>     > /* BOSS Katana amplifiers and many other newer BOSS devices do not need
>     quirks
>     > */
>     >
>     > There's probably others too, such as the GT-100 (I believe the GT-001
>     and
>     > GT-100 have similar hardware).
>     >
>     > My question is, should this just be submitted as a patch to pcm.c or
>     would it
>     > be better handled in quirks and, if so, how?
>     >
>     > Or something else?
>    
>     Do we really need this change at all?  I looked at the code again, and
>     I noticed that basically the function should return 0 without setting
>     anything else even if you don't have the explicit ID checks there.
>    
>     The function looks like:
>    
>     static int set_sync_ep_implicit_fb_quirk(struct snd_usb_substream *subs,
>                                              struct usb_device *dev,
>                                              struct usb_interface_descriptor
>     *altsd,
>                                              unsigned int attr)
>     {
>             ....
>             switch (subs->stream->chip->usb_id) {
>             ....
>             case USB_ID(0x0582, 0x01d8): /* BOSS Katana */
>                     /* BOSS Katana amplifiers do not need quirks */
>                     return 0;
>             }
>    
>             if (attr == USB_ENDPOINT_SYNC_ASYNC &&
>                 altsd->bInterfaceClass == USB_CLASS_VENDOR_SPEC &&
>                 altsd->bInterfaceProtocol == 2 &&
>                 altsd->bNumEndpoints == 1 &&
>                 USB_ID_VENDOR(subs->stream->chip->usb_id) == 0x0582 /* Roland
>     */ &&
>                 search_roland_implicit_fb(dev, altsd->bInterfaceNumber + 1,
>                                           altsd->bAlternateSetting,
>                                           &alts, &ep) >= 0) {
>                     goto add_sync_ep;
>             }
>    
>             /* No quirk */
>             return 0;
>    
>     ... and the lengthy if-conditions after the switch/case is applied
>     only for Roland devices, hence it shouldn't influence on BOSS
>     devices.  After that point, the immediate return with 0, which is the
>     same as we do in switch/case.  So the explicit check of BOSS devices
>     there looks superfluous.
> 
>     thanks,
>    
>     Takashi
> 
> --
> --
> Keith A Milner
> 
> 

Re: [alsa-devel] [PATCH] ALSA: usb-audio: Disable quirks for BOSS Katana amplifiers

[Mailing Lists]

Yes, and I don't think this is practical (at least, not obviously).

The "Roland" vs "BOSS" thing is pure branding. I have BOSS branded devices,
like the JS-8, which work perfectly without the patch as an example. It
wouldn't surprise me if there are recent Roland branded devices which
require the patch.

So I, personally, think it is beyond brand and is device range or
generation specific. I guess it is possible there may be some technical
parameter within the device descriptor which could indicate which variant
the device is, but I don't know what that might be (if at all). At this
point I think we probably have to apply a conditional setting based on the
Product ID.

Given that, is it best to continue hacking these into pcm.c, or should we
be looking at a quirks-table way to describe these?

Cheers,

Keith



On Wed, 14 Oct 2020 at 14:47, Takashi Iwai <tiwai@suse.de> wrote:

> On Wed, 14 Oct 2020 15:33:03 +0200,
> Mailing Lists wrote:
> >
> > Thanks for the response Takashi,
> >
> > How should this be distinguishing between Roland and BOSS? They both
> have the
> > vendor ID 0x0582.
>
> Ah, right, I missed that point :-<
>
> So the question would be rather how to detect BOSS devices
> effectively...
>
>
> thanks,
>
> Takashi
>
> >
> > Cheers,
> >
> > Keith
> >
> > On Wed, 14 Oct 2020 at 14:09, Takashi Iwai <tiwai@suse.de> wrote:
> >
> >     On Wed, 14 Oct 2020 14:17:35 +0200,
> >     Mailing Lists wrote:
> >     >
> >     > Following up on this, it appears there are a bunch of the
> >     newer-generation
> >     > Roland/Boss devices which need similar treatment.
> >     >
> >     > So far I have tested the GT-1, the GT-001, and the BR-80, and
> others
> >     have
> >     > reported the RC-300 as working with similar modifications. I have
> been
> >     using
> >     > the following change to the code in pcm.c
> set_sync_ep_implicit_fb_quirk:
> >     >
> >     >     case USB_ID(0x0582, 0x01d8): /* BOSS Katana */
> >     >     case USB_ID(0x0582, 0x0130): /* BOSS Micro BR-80 */
> >     >     case USB_ID(0x0582, 0x0138): /* BOSS RC-300 */
> >     >     case USB_ID(0x0582, 0x01d6): /* BOSS GT-1 */
> >     >     case USB_ID(0x0582, 0x01e5): /* BOSS GT-001 */
> >     > /* BOSS Katana amplifiers and many other newer BOSS devices do not
> need
> >     quirks
> >     > */
> >     >
> >     > There's probably others too, such as the GT-100 (I believe the
> GT-001
> >     and
> >     > GT-100 have similar hardware).
> >     >
> >     > My question is, should this just be submitted as a patch to pcm.c
> or
> >     would it
> >     > be better handled in quirks and, if so, how?
> >     >
> >     > Or something else?
> >
> >     Do we really need this change at all?  I looked at the code again,
> and
> >     I noticed that basically the function should return 0 without setting
> >     anything else even if you don't have the explicit ID checks there.
> >
> >     The function looks like:
> >
> >     static int set_sync_ep_implicit_fb_quirk(struct snd_usb_substream
> *subs,
> >                                              struct usb_device *dev,
> >                                              struct
> usb_interface_descriptor
> >     *altsd,
> >                                              unsigned int attr)
> >     {
> >             ....
> >             switch (subs->stream->chip->usb_id) {
> >             ....
> >             case USB_ID(0x0582, 0x01d8): /* BOSS Katana */
> >                     /* BOSS Katana amplifiers do not need quirks */
> >                     return 0;
> >             }
> >
> >             if (attr == USB_ENDPOINT_SYNC_ASYNC &&
> >                 altsd->bInterfaceClass == USB_CLASS_VENDOR_SPEC &&
> >                 altsd->bInterfaceProtocol == 2 &&
> >                 altsd->bNumEndpoints == 1 &&
> >                 USB_ID_VENDOR(subs->stream->chip->usb_id) == 0x0582 /*
> Roland
> >     */ &&
> >                 search_roland_implicit_fb(dev, altsd->bInterfaceNumber +
> 1,
> >                                           altsd->bAlternateSetting,
> >                                           &alts, &ep) >= 0) {
> >                     goto add_sync_ep;
> >             }
> >
> >             /* No quirk */
> >             return 0;
> >
> >     ... and the lengthy if-conditions after the switch/case is applied
> >     only for Roland devices, hence it shouldn't influence on BOSS
> >     devices.  After that point, the immediate return with 0, which is the
> >     same as we do in switch/case.  So the explicit check of BOSS devices
> >     there looks superfluous.
> >
> >     thanks,
> >
> >     Takashi
> >
> > --
> > --
> > Keith A Milner
> >
> >
>


-- 
-- 
Keith A Milner

Re: [alsa-devel] [PATCH] ALSA: usb-audio: Disable quirks for BOSS Katana amplifiers

[Takashi Iwai]

On Wed, 14 Oct 2020 15:56:32 +0200,
Mailing Lists wrote:
> 
> Yes, and I don't think this is practical (at least, not obviously).
> 
> The "Roland" vs "BOSS" thing is pure branding. I have BOSS branded devices,
> like the JS-8, which work perfectly without the patch as an example. It
> wouldn't surprise me if there are recent Roland branded devices which require
> the patch.
> 
> So I, personally, think it is beyond brand and is device range or generation
> specific. I guess it is possible there may be some technical parameter within
> the device descriptor which could indicate which variant the device is, but I
> don't know what that might be (if at all). At this point I think we probably
> have to apply a conditional setting based on the Product ID.
> 
> Given that, is it best to continue hacking these into pcm.c, or should we be
> looking at a quirks-table way to describe these?

Currently it's better to grow the explicit allow-list, I suppose.
Those are still handful, hence manageable enough.

But, we should consider improving search_roland_implicit_fb(), too.
Both actions don't conflict, and once after we establish the better
implicit-fb check, the allow-list can be dropped.


thanks,

Takashi

> 
> Cheers,
> 
> Keith
> 
> On Wed, 14 Oct 2020 at 14:47, Takashi Iwai <tiwai@suse.de> wrote:
> 
>     On Wed, 14 Oct 2020 15:33:03 +0200,
>     Mailing Lists wrote:
>     >
>     > Thanks for the response Takashi,
>     >
>     > How should this be distinguishing between Roland and BOSS? They both
>     have the
>     > vendor ID 0x0582.
>    
>     Ah, right, I missed that point :-<
>    
>     So the question would be rather how to detect BOSS devices
>     effectively...
> 
>     thanks,
>    
>     Takashi
>    
>     >
>     > Cheers,
>     >
>     > Keith
>     >
>     > On Wed, 14 Oct 2020 at 14:09, Takashi Iwai <tiwai@suse.de> wrote:
>     >
>     >     On Wed, 14 Oct 2020 14:17:35 +0200,
>     >     Mailing Lists wrote:
>     >     >
>     >     > Following up on this, it appears there are a bunch of the
>     >     newer-generation
>     >     > Roland/Boss devices which need similar treatment.
>     >     >
>     >     > So far I have tested the GT-1, the GT-001, and the BR-80, and
>     others
>     >     have
>     >     > reported the RC-300 as working with similar modifications. I have
>     been
>     >     using
>     >     > the following change to the code in pcm.c
>     set_sync_ep_implicit_fb_quirk:
>     >     >
>     >     >     case USB_ID(0x0582, 0x01d8): /* BOSS Katana */
>     >     >     case USB_ID(0x0582, 0x0130): /* BOSS Micro BR-80 */
>     >     >     case USB_ID(0x0582, 0x0138): /* BOSS RC-300 */
>     >     >     case USB_ID(0x0582, 0x01d6): /* BOSS GT-1 */
>     >     >     case USB_ID(0x0582, 0x01e5): /* BOSS GT-001 */
>     >     > /* BOSS Katana amplifiers and many other newer BOSS devices do not
>     need
>     >     quirks
>     >     > */
>     >     >
>     >     > There's probably others too, such as the GT-100 (I believe the
>     GT-001
>     >     and
>     >     > GT-100 have similar hardware).
>     >     >
>     >     > My question is, should this just be submitted as a patch to pcm.c
>     or
>     >     would it
>     >     > be better handled in quirks and, if so, how?
>     >     >
>     >     > Or something else?
>     >   
>     >     Do we really need this change at all?  I looked at the code again,
>     and
>     >     I noticed that basically the function should return 0 without
>     setting
>     >     anything else even if you don't have the explicit ID checks there.
>     >   
>     >     The function looks like:
>     >   
>     >     static int set_sync_ep_implicit_fb_quirk(struct snd_usb_substream
>     *subs,
>     >                                              struct usb_device *dev,
>     >                                              struct
>     usb_interface_descriptor
>     >     *altsd,
>     >                                              unsigned int attr)
>     >     {
>     >             ....
>     >             switch (subs->stream->chip->usb_id) {
>     >             ....
>     >             case USB_ID(0x0582, 0x01d8): /* BOSS Katana */
>     >                     /* BOSS Katana amplifiers do not need quirks */
>     >                     return 0;
>     >             }
>     >   
>     >             if (attr == USB_ENDPOINT_SYNC_ASYNC &&
>     >                 altsd->bInterfaceClass == USB_CLASS_VENDOR_SPEC &&
>     >                 altsd->bInterfaceProtocol == 2 &&
>     >                 altsd->bNumEndpoints == 1 &&
>     >                 USB_ID_VENDOR(subs->stream->chip->usb_id) == 0x0582 /*
>     Roland
>     >     */ &&
>     >                 search_roland_implicit_fb(dev, altsd->bInterfaceNumber +
>     1,
>     >                                           altsd->bAlternateSetting,
>     >                                           &alts, &ep) >= 0) {
>     >                     goto add_sync_ep;
>     >             }
>     >   
>     >             /* No quirk */
>     >             return 0;
>     >   
>     >     ... and the lengthy if-conditions after the switch/case is applied
>     >     only for Roland devices, hence it shouldn't influence on BOSS
>     >     devices.  After that point, the immediate return with 0, which is
>     the
>     >     same as we do in switch/case.  So the explicit check of BOSS devices
>     >     there looks superfluous.
>     >
>     >     thanks,
>     >   
>     >     Takashi
>     >
>     > --
>     > --
>     > Keith A Milner
>     >
>     >
> 
> --
> --
> Keith A Milner
> 
> 

Re: [alsa-devel] [PATCH] ALSA: usb-audio: Disable quirks for BOSS Katana amplifiers

[Mailing Lists]

OK, I will do that.

Quick question: what is the best git I should clone to create patches
against these days? I've been out of the loop for a few years now.

Cheers,

Keith

On Wed, 14 Oct 2020 at 15:00, Takashi Iwai <tiwai@suse.de> wrote:

> On Wed, 14 Oct 2020 15:56:32 +0200,
> Mailing Lists wrote:
> >
> > Yes, and I don't think this is practical (at least, not obviously).
> >
> > The "Roland" vs "BOSS" thing is pure branding. I have BOSS branded
> devices,
> > like the JS-8, which work perfectly without the patch as an example. It
> > wouldn't surprise me if there are recent Roland branded devices which
> require
> > the patch.
> >
> > So I, personally, think it is beyond brand and is device range or
> generation
> > specific. I guess it is possible there may be some technical
> parameter within
> > the device descriptor which could indicate which variant the device is,
> but I
> > don't know what that might be (if at all). At this point I think we
> probably
> > have to apply a conditional setting based on the Product ID.
> >
> > Given that, is it best to continue hacking these into pcm.c, or should
> we be
> > looking at a quirks-table way to describe these?
>
> Currently it's better to grow the explicit allow-list, I suppose.
> Those are still handful, hence manageable enough.
>
> But, we should consider improving search_roland_implicit_fb(), too.
> Both actions don't conflict, and once after we establish the better
> implicit-fb check, the allow-list can be dropped.
>
>
> thanks,
>
> Takashi
>
> >
> > Cheers,
> >
> > Keith
> >
> > On Wed, 14 Oct 2020 at 14:47, Takashi Iwai <tiwai@suse.de> wrote:
> >
> >     On Wed, 14 Oct 2020 15:33:03 +0200,
> >     Mailing Lists wrote:
> >     >
> >     > Thanks for the response Takashi,
> >     >
> >     > How should this be distinguishing between Roland and BOSS? They
> both
> >     have the
> >     > vendor ID 0x0582.
> >
> >     Ah, right, I missed that point :-<
> >
> >     So the question would be rather how to detect BOSS devices
> >     effectively...
> >
> >     thanks,
> >
> >     Takashi
> >
> >     >
> >     > Cheers,
> >     >
> >     > Keith
> >     >
> >     > On Wed, 14 Oct 2020 at 14:09, Takashi Iwai <tiwai@suse.de> wrote:
> >     >
> >     >     On Wed, 14 Oct 2020 14:17:35 +0200,
> >     >     Mailing Lists wrote:
> >     >     >
> >     >     > Following up on this, it appears there are a bunch of the
> >     >     newer-generation
> >     >     > Roland/Boss devices which need similar treatment.
> >     >     >
> >     >     > So far I have tested the GT-1, the GT-001, and the BR-80, and
> >     others
> >     >     have
> >     >     > reported the RC-300 as working with similar modifications. I
> have
> >     been
> >     >     using
> >     >     > the following change to the code in pcm.c
> >     set_sync_ep_implicit_fb_quirk:
> >     >     >
> >     >     >     case USB_ID(0x0582, 0x01d8): /* BOSS Katana */
> >     >     >     case USB_ID(0x0582, 0x0130): /* BOSS Micro BR-80 */
> >     >     >     case USB_ID(0x0582, 0x0138): /* BOSS RC-300 */
> >     >     >     case USB_ID(0x0582, 0x01d6): /* BOSS GT-1 */
> >     >     >     case USB_ID(0x0582, 0x01e5): /* BOSS GT-001 */
> >     >     > /* BOSS Katana amplifiers and many other newer BOSS devices
> do not
> >     need
> >     >     quirks
> >     >     > */
> >     >     >
> >     >     > There's probably others too, such as the GT-100 (I believe
> the
> >     GT-001
> >     >     and
> >     >     > GT-100 have similar hardware).
> >     >     >
> >     >     > My question is, should this just be submitted as a patch to
> pcm.c
> >     or
> >     >     would it
> >     >     > be better handled in quirks and, if so, how?
> >     >     >
> >     >     > Or something else?
> >     >
> >     >     Do we really need this change at all?  I looked at the code
> again,
> >     and
> >     >     I noticed that basically the function should return 0 without
> >     setting
> >     >     anything else even if you don't have the explicit ID checks
> there.
> >     >
> >     >     The function looks like:
> >     >
> >     >     static int set_sync_ep_implicit_fb_quirk(struct
> snd_usb_substream
> >     *subs,
> >     >                                              struct usb_device
> *dev,
> >     >                                              struct
> >     usb_interface_descriptor
> >     >     *altsd,
> >     >                                              unsigned int attr)
> >     >     {
> >     >             ....
> >     >             switch (subs->stream->chip->usb_id) {
> >     >             ....
> >     >             case USB_ID(0x0582, 0x01d8): /* BOSS Katana */
> >     >                     /* BOSS Katana amplifiers do not need quirks */
> >     >                     return 0;
> >     >             }
> >     >
> >     >             if (attr == USB_ENDPOINT_SYNC_ASYNC &&
> >     >                 altsd->bInterfaceClass == USB_CLASS_VENDOR_SPEC &&
> >     >                 altsd->bInterfaceProtocol == 2 &&
> >     >                 altsd->bNumEndpoints == 1 &&
> >     >                 USB_ID_VENDOR(subs->stream->chip->usb_id) ==
> 0x0582 /*
> >     Roland
> >     >     */ &&
> >     >                 search_roland_implicit_fb(dev,
> altsd->bInterfaceNumber +
> >     1,
> >     >                                           altsd->bAlternateSetting,
> >     >                                           &alts, &ep) >= 0) {
> >     >                     goto add_sync_ep;
> >     >             }
> >     >
> >     >             /* No quirk */
> >     >             return 0;
> >     >
> >     >     ... and the lengthy if-conditions after the switch/case is
> applied
> >     >     only for Roland devices, hence it shouldn't influence on BOSS
> >     >     devices.  After that point, the immediate return with 0, which
> is
> >     the
> >     >     same as we do in switch/case.  So the explicit check of BOSS
> devices
> >     >     there looks superfluous.
> >     >
> >     >     thanks,
> >     >
> >     >     Takashi
> >     >
> >     > --
> >     > --
> >     > Keith A Milner
> >     >
> >     >
> >
> > --
> > --
> > Keith A Milner
> >
> >
>


-- 
-- 
Keith A Milner

Re: [alsa-devel] [PATCH] ALSA: usb-audio: Disable quirks for BOSS Katana amplifiers

[Takashi Iwai]

On Wed, 14 Oct 2020 16:31:02 +0200,
Mailing Lists wrote:
> 
> OK, I will do that.
> 
> Quick question: what is the best git I should clone to create patches against
> these days? I've been out of the loop for a few years now.

At best, for-linus branch of my sound.git tree
  git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git

There is a copy in github, too.


Takashi

> 
> Cheers,
> 
> Keith
> 
> On Wed, 14 Oct 2020 at 15:00, Takashi Iwai <tiwai@suse.de> wrote:
> 
>     On Wed, 14 Oct 2020 15:56:32 +0200,
>     Mailing Lists wrote:
>     >
>     > Yes, and I don't think this is practical (at least, not obviously).
>     >
>     > The "Roland" vs "BOSS" thing is pure branding. I have BOSS branded
>     devices,
>     > like the JS-8, which work perfectly without the patch as an example. It
>     > wouldn't surprise me if there are recent Roland branded devices which
>     require
>     > the patch.
>     >
>     > So I, personally, think it is beyond brand and is device range or
>     generation
>     > specific. I guess it is possible there may be some technical
>     parameter within
>     > the device descriptor which could indicate which variant the device is,
>     but I
>     > don't know what that might be (if at all). At this point I think we
>     probably
>     > have to apply a conditional setting based on the Product ID.
>     >
>     > Given that, is it best to continue hacking these into pcm.c, or should
>     we be
>     > looking at a quirks-table way to describe these?
>    
>     Currently it's better to grow the explicit allow-list, I suppose.
>     Those are still handful, hence manageable enough.
>    
>     But, we should consider improving search_roland_implicit_fb(), too.
>     Both actions don't conflict, and once after we establish the better
>     implicit-fb check, the allow-list can be dropped.
> 
>     thanks,
>    
>     Takashi
>    
>     >
>     > Cheers,
>     >
>     > Keith
>     >
>     > On Wed, 14 Oct 2020 at 14:47, Takashi Iwai <tiwai@suse.de> wrote:
>     >
>     >     On Wed, 14 Oct 2020 15:33:03 +0200,
>     >     Mailing Lists wrote:
>     >     >
>     >     > Thanks for the response Takashi,
>     >     >
>     >     > How should this be distinguishing between Roland and BOSS? They
>     both
>     >     have the
>     >     > vendor ID 0x0582.
>     >   
>     >     Ah, right, I missed that point :-<
>     >   
>     >     So the question would be rather how to detect BOSS devices
>     >     effectively...
>     >
>     >     thanks,
>     >   
>     >     Takashi
>     >   
>     >     >
>     >     > Cheers,
>     >     >
>     >     > Keith
>     >     >
>     >     > On Wed, 14 Oct 2020 at 14:09, Takashi Iwai <tiwai@suse.de> wrote:
>     >     >
>     >     >     On Wed, 14 Oct 2020 14:17:35 +0200,
>     >     >     Mailing Lists wrote:
>     >     >     >
>     >     >     > Following up on this, it appears there are a bunch of the
>     >     >     newer-generation
>     >     >     > Roland/Boss devices which need similar treatment.
>     >     >     >
>     >     >     > So far I have tested the GT-1, the GT-001, and the BR-80,
>     and
>     >     others
>     >     >     have
>     >     >     > reported the RC-300 as working with similar modifications. I
>     have
>     >     been
>     >     >     using
>     >     >     > the following change to the code in pcm.c
>     >     set_sync_ep_implicit_fb_quirk:
>     >     >     >
>     >     >     >     case USB_ID(0x0582, 0x01d8): /* BOSS Katana */
>     >     >     >     case USB_ID(0x0582, 0x0130): /* BOSS Micro BR-80 */
>     >     >     >     case USB_ID(0x0582, 0x0138): /* BOSS RC-300 */
>     >     >     >     case USB_ID(0x0582, 0x01d6): /* BOSS GT-1 */
>     >     >     >     case USB_ID(0x0582, 0x01e5): /* BOSS GT-001 */
>     >     >     > /* BOSS Katana amplifiers and many other newer BOSS devices
>     do not
>     >     need
>     >     >     quirks
>     >     >     > */
>     >     >     >
>     >     >     > There's probably others too, such as the GT-100 (I believe
>     the
>     >     GT-001
>     >     >     and
>     >     >     > GT-100 have similar hardware).
>     >     >     >
>     >     >     > My question is, should this just be submitted as a patch to
>     pcm.c
>     >     or
>     >     >     would it
>     >     >     > be better handled in quirks and, if so, how?
>     >     >     >
>     >     >     > Or something else?
>     >     >   
>     >     >     Do we really need this change at all?  I looked at the code
>     again,
>     >     and
>     >     >     I noticed that basically the function should return 0 without
>     >     setting
>     >     >     anything else even if you don't have the explicit ID checks
>     there.
>     >     >   
>     >     >     The function looks like:
>     >     >   
>     >     >     static int set_sync_ep_implicit_fb_quirk(struct
>     snd_usb_substream
>     >     *subs,
>     >     >                                              struct usb_device
>     *dev,
>     >     >                                              struct
>     >     usb_interface_descriptor
>     >     >     *altsd,
>     >     >                                              unsigned int attr)
>     >     >     {
>     >     >             ....
>     >     >             switch (subs->stream->chip->usb_id) {
>     >     >             ....
>     >     >             case USB_ID(0x0582, 0x01d8): /* BOSS Katana */
>     >     >                     /* BOSS Katana amplifiers do not need quirks *
>     /
>     >     >                     return 0;
>     >     >             }
>     >     >   
>     >     >             if (attr == USB_ENDPOINT_SYNC_ASYNC &&
>     >     >                 altsd->bInterfaceClass == USB_CLASS_VENDOR_SPEC &&
>     >     >                 altsd->bInterfaceProtocol == 2 &&
>     >     >                 altsd->bNumEndpoints == 1 &&
>     >     >                 USB_ID_VENDOR(subs->stream->chip->usb_id) ==
>     0x0582 /*
>     >     Roland
>     >     >     */ &&
>     >     >                 search_roland_implicit_fb(dev, altsd->
>     bInterfaceNumber +
>     >     1,
>     >     >                                           altsd->
>     bAlternateSetting,
>     >     >                                           &alts, &ep) >= 0) {
>     >     >                     goto add_sync_ep;
>     >     >             }
>     >     >   
>     >     >             /* No quirk */
>     >     >             return 0;
>     >     >   
>     >     >     ... and the lengthy if-conditions after the switch/case is
>     applied
>     >     >     only for Roland devices, hence it shouldn't influence on BOSS
>     >     >     devices.  After that point, the immediate return with 0, which
>     is
>     >     the
>     >     >     same as we do in switch/case.  So the explicit check of BOSS
>     devices
>     >     >     there looks superfluous.
>     >     >
>     >     >     thanks,
>     >     >   
>     >     >     Takashi
>     >     >
>     >     > --
>     >     > --
>     >     > Keith A Milner
>     >     >
>     >     >
>     >
>     > --
>     > --
>     > Keith A Milner
>     >
>     >
> 
> --
> --
> Keith A Milner
> 
> 

Re: [alsa-devel] [PATCH] ALSA: usb-audio: Disable quirks for BOSS Katana amplifiers

[Mike Oliphant]

When I tried this change earlier this year on the BOSS GT-1, it enabled
sound output on the card (which was not previously working), but with
significant issues. It resulted in frequent pops and crackles - presumably
because of the loss of synchronization using implicit feedback.

This was the fix that ended up working for me:

https://mailman.alsa-project.org/pipermail/alsa-devel/2020-January/161951.html

But maybe something else has changed in the handling of implicit feedback
since then?

Mike

On Wed, Oct 14, 2020 at 5:17 AM Mailing Lists <maillist@superlative.org>
wrote:

> Following up on this, it appears there are a bunch of the newer-generation
> Roland/Boss devices which need similar treatment.
>
> So far I have tested the GT-1, the GT-001, and the BR-80, and others have
> reported the RC-300 as working with similar modifications. I have been
> using the following change to the code in pcm.c
> set_sync_ep_implicit_fb_quirk:
>
>     case USB_ID(0x0582, 0x01d8): /* BOSS Katana */
>     case USB_ID(0x0582, 0x0130): /* BOSS Micro BR-80 */
>     case USB_ID(0x0582, 0x0138): /* BOSS RC-300 */
>     case USB_ID(0x0582, 0x01d6): /* BOSS GT-1 */
>     case USB_ID(0x0582, 0x01e5): /* BOSS GT-001 */
> /* BOSS Katana amplifiers and many other newer BOSS devices do not need
> quirks */
>
> There's probably others too, such as the GT-100 (I believe the GT-001 and
> GT-100 have similar hardware).
>
> My question is, should this just be submitted as a patch to pcm.c or would
> it be better handled in quirks and, if so, how?
>
> Or something else?
>
> Personally, I dislike the approach of hard-coding exceptions into core
> code as it seems that's what quirks are there for, but there seems to be a
> whole bunch of exceptions in there already.
>
> Cheers,
>
> Keith
>
> On Thu, 17 Oct 2019 at 09:20, Takashi Iwai <tiwai@suse.de> wrote:
>
>> On Fri, 11 Oct 2019 19:19:36 +0200,
>> Szabolcs Szőke wrote:
>> >
>> > BOSS Katana amplifiers cannot be used for recording or playback if
>> quirks
>> > are applied
>> >
>> > BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=195223
>> > Signed-off-by: Szabolcs Szőke <szszoke.code@gmail.com>
>>
>> Applied now.  Thanks.
>>
>>
>> Takashi
>>
>> >
>> > ---
>> >  sound/usb/pcm.c | 3 +++
>> >  1 file changed, 3 insertions(+)
>> >
>> > diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c
>> > index 33cd26763c0e..daadb0c66eee 100644
>> > --- a/sound/usb/pcm.c
>> > +++ b/sound/usb/pcm.c
>> > @@ -348,6 +348,9 @@ static int set_sync_ep_implicit_fb_quirk(struct
>> snd_usb_substream *subs,
>> >               ep = 0x84;
>> >               ifnum = 0;
>> >               goto add_sync_ep_from_ifnum;
>> > +     case USB_ID(0x0582, 0x01d8): /* BOSS Katana */
>> > +             /* BOSS Katana amplifiers do not need quirks */
>> > +             return 0;
>> >       }
>> >
>> >       if (attr == USB_ENDPOINT_SYNC_ASYNC &&
>> > --
>> > 2.20.1
>> >
>> _______________________________________________
>> Alsa-devel mailing list
>> Alsa-devel@alsa-project.org
>> https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>>
>
>
> --
> --
> Keith A Milner
>

Re: [alsa-devel] [PATCH] ALSA: usb-audio: Disable quirks for BOSS Katana amplifiers

[Mailing Lists]

Hi Mike,
That's odd. I've been using the patches in this thread with both my GT-001
and my GT-1 with no issues for a few weeks now. Of course that might be
pure dumb luck and differences in hardware, interrupts, and so on.

Cheers,

Keith

On Wed, 14 Oct 2020 at 16:19, Mike Oliphant <oliphant@nostatic.org> wrote:

> When I tried this change earlier this year on the BOSS GT-1, it enabled
> sound output on the card (which was not previously working), but with
> significant issues. It resulted in frequent pops and crackles - presumably
> because of the loss of synchronization using implicit feedback.
>
> This was the fix that ended up working for me:
>
>
> https://mailman.alsa-project.org/pipermail/alsa-devel/2020-January/161951.html
>
> But maybe something else has changed in the handling of implicit feedback
> since then?
>
> Mike
>
> On Wed, Oct 14, 2020 at 5:17 AM Mailing Lists <maillist@superlative.org>
> wrote:
>
>> Following up on this, it appears there are a bunch of the
>> newer-generation Roland/Boss devices which need similar treatment.
>>
>> So far I have tested the GT-1, the GT-001, and the BR-80, and others have
>> reported the RC-300 as working with similar modifications. I have been
>> using the following change to the code in pcm.c
>> set_sync_ep_implicit_fb_quirk:
>>
>>     case USB_ID(0x0582, 0x01d8): /* BOSS Katana */
>>     case USB_ID(0x0582, 0x0130): /* BOSS Micro BR-80 */
>>     case USB_ID(0x0582, 0x0138): /* BOSS RC-300 */
>>     case USB_ID(0x0582, 0x01d6): /* BOSS GT-1 */
>>     case USB_ID(0x0582, 0x01e5): /* BOSS GT-001 */
>> /* BOSS Katana amplifiers and many other newer BOSS devices do not need
>> quirks */
>>
>> There's probably others too, such as the GT-100 (I believe the GT-001 and
>> GT-100 have similar hardware).
>>
>> My question is, should this just be submitted as a patch to pcm.c or
>> would it be better handled in quirks and, if so, how?
>>
>> Or something else?
>>
>> Personally, I dislike the approach of hard-coding exceptions into core
>> code as it seems that's what quirks are there for, but there seems to be a
>> whole bunch of exceptions in there already.
>>
>> Cheers,
>>
>> Keith
>>
>> On Thu, 17 Oct 2019 at 09:20, Takashi Iwai <tiwai@suse.de> wrote:
>>
>>> On Fri, 11 Oct 2019 19:19:36 +0200,
>>> Szabolcs Szőke wrote:
>>> >
>>> > BOSS Katana amplifiers cannot be used for recording or playback if
>>> quirks
>>> > are applied
>>> >
>>> > BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=195223
>>> > Signed-off-by: Szabolcs Szőke <szszoke.code@gmail.com>
>>>
>>> Applied now.  Thanks.
>>>
>>>
>>> Takashi
>>>
>>> >
>>> > ---
>>> >  sound/usb/pcm.c | 3 +++
>>> >  1 file changed, 3 insertions(+)
>>> >
>>> > diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c
>>> > index 33cd26763c0e..daadb0c66eee 100644
>>> > --- a/sound/usb/pcm.c
>>> > +++ b/sound/usb/pcm.c
>>> > @@ -348,6 +348,9 @@ static int set_sync_ep_implicit_fb_quirk(struct
>>> snd_usb_substream *subs,
>>> >               ep = 0x84;
>>> >               ifnum = 0;
>>> >               goto add_sync_ep_from_ifnum;
>>> > +     case USB_ID(0x0582, 0x01d8): /* BOSS Katana */
>>> > +             /* BOSS Katana amplifiers do not need quirks */
>>> > +             return 0;
>>> >       }
>>> >
>>> >       if (attr == USB_ENDPOINT_SYNC_ASYNC &&
>>> > --
>>> > 2.20.1
>>> >
>>> _______________________________________________
>>> Alsa-devel mailing list
>>> Alsa-devel@alsa-project.org
>>> https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>>>
>>
>>
>> --
>> --
>> Keith A Milner
>>
>

-- 
-- 
Keith A Milner

Re: [alsa-devel] [PATCH] ALSA: usb-audio: Disable quirks for BOSS Katana amplifiers

[Mike Oliphant]

Keith - are you getting an implicit feedback endpoint created when you run
with the patch?

When I patched the GT-1 device ID into the quirk code, I ended up with no
implicit feedback endpoint created. Without running in implicit feedback
mode, I assume that you are relying on how well the clocks match. In my
case, my card's clock was a bit fast. If I hardcoded the sample rate in
'sound/usb/format.c' to 44105, my pops and crackles mostly went away - more
like every few minutes instead of every few seconds.

Maybe your card just has a clock closer to 44100? Or, as I said in my last
message, maybe something else has changed in the kernel since earlier this
year?

Mike

On Wed, Oct 14, 2020 at 8:35 AM Mailing Lists <maillist@superlative.org>
wrote:

> Hi Mike,
> That's odd. I've been using the patches in this thread with both my GT-001
> and my GT-1 with no issues for a few weeks now. Of course that might be
> pure dumb luck and differences in hardware, interrupts, and so on.
>
> Cheers,
>
> Keith
>
> On Wed, 14 Oct 2020 at 16:19, Mike Oliphant <oliphant@nostatic.org> wrote:
>
>> When I tried this change earlier this year on the BOSS GT-1, it enabled
>> sound output on the card (which was not previously working), but with
>> significant issues. It resulted in frequent pops and crackles - presumably
>> because of the loss of synchronization using implicit feedback.
>>
>> This was the fix that ended up working for me:
>>
>>
>> https://mailman.alsa-project.org/pipermail/alsa-devel/2020-January/161951.html
>>
>> But maybe something else has changed in the handling of implicit feedback
>> since then?
>>
>> Mike
>>
>> On Wed, Oct 14, 2020 at 5:17 AM Mailing Lists <maillist@superlative.org>
>> wrote:
>>
>>> Following up on this, it appears there are a bunch of the
>>> newer-generation Roland/Boss devices which need similar treatment.
>>>
>>> So far I have tested the GT-1, the GT-001, and the BR-80, and others
>>> have reported the RC-300 as working with similar modifications. I have been
>>> using the following change to the code in pcm.c
>>> set_sync_ep_implicit_fb_quirk:
>>>
>>>     case USB_ID(0x0582, 0x01d8): /* BOSS Katana */
>>>     case USB_ID(0x0582, 0x0130): /* BOSS Micro BR-80 */
>>>     case USB_ID(0x0582, 0x0138): /* BOSS RC-300 */
>>>     case USB_ID(0x0582, 0x01d6): /* BOSS GT-1 */
>>>     case USB_ID(0x0582, 0x01e5): /* BOSS GT-001 */
>>> /* BOSS Katana amplifiers and many other newer BOSS devices do not need
>>> quirks */
>>>
>>> There's probably others too, such as the GT-100 (I believe the GT-001
>>> and GT-100 have similar hardware).
>>>
>>> My question is, should this just be submitted as a patch to pcm.c or
>>> would it be better handled in quirks and, if so, how?
>>>
>>> Or something else?
>>>
>>> Personally, I dislike the approach of hard-coding exceptions into core
>>> code as it seems that's what quirks are there for, but there seems to be a
>>> whole bunch of exceptions in there already.
>>>
>>> Cheers,
>>>
>>> Keith
>>>
>>> On Thu, 17 Oct 2019 at 09:20, Takashi Iwai <tiwai@suse.de> wrote:
>>>
>>>> On Fri, 11 Oct 2019 19:19:36 +0200,
>>>> Szabolcs Szőke wrote:
>>>> >
>>>> > BOSS Katana amplifiers cannot be used for recording or playback if
>>>> quirks
>>>> > are applied
>>>> >
>>>> > BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=195223
>>>> > Signed-off-by: Szabolcs Szőke <szszoke.code@gmail.com>
>>>>
>>>> Applied now.  Thanks.
>>>>
>>>>
>>>> Takashi
>>>>
>>>> >
>>>> > ---
>>>> >  sound/usb/pcm.c | 3 +++
>>>> >  1 file changed, 3 insertions(+)
>>>> >
>>>> > diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c
>>>> > index 33cd26763c0e..daadb0c66eee 100644
>>>> > --- a/sound/usb/pcm.c
>>>> > +++ b/sound/usb/pcm.c
>>>> > @@ -348,6 +348,9 @@ static int set_sync_ep_implicit_fb_quirk(struct
>>>> snd_usb_substream *subs,
>>>> >               ep = 0x84;
>>>> >               ifnum = 0;
>>>> >               goto add_sync_ep_from_ifnum;
>>>> > +     case USB_ID(0x0582, 0x01d8): /* BOSS Katana */
>>>> > +             /* BOSS Katana amplifiers do not need quirks */
>>>> > +             return 0;
>>>> >       }
>>>> >
>>>> >       if (attr == USB_ENDPOINT_SYNC_ASYNC &&
>>>> > --
>>>> > 2.20.1
>>>> >
>>>> _______________________________________________
>>>> Alsa-devel mailing list
>>>> Alsa-devel@alsa-project.org
>>>> https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>>>>
>>>
>>>
>>> --
>>> --
>>> Keith A Milner
>>>
>>
>
> --
> --
> Keith A Milner
>

Re: [alsa-devel] [PATCH] ALSA: usb-audio: Disable quirks for BOSS Katana amplifiers

[Mailing Lists]

On Wed, 14 Oct 2020 at 17:12, Mike Oliphant <oliphant@nostatic.org> wrote:

> Keith - are you getting an implicit feedback endpoint created when you run
> with the patch?
>

Hi Mike,

It appears that I do. For reference I'm on kernel 5.4.0-51:

Bus 001 Device 007: ID 0582:01d6 Roland Corp. GT-1
Device Descriptor:
 bLength                18
 bDescriptorType         1
 bcdUSB               2.00
 bDeviceClass          255 Vendor Specific Class
 bDeviceSubClass         0
 bDeviceProtocol       255
 bMaxPacketSize0        64
 idVendor           0x0582 Roland Corp.
 idProduct          0x01d6
 bcdDevice            0.00
 iManufacturer           1 BOSS
 iProduct                2 GT-1
 iSerial                 0
 bNumConfigurations      1
 Configuration Descriptor:
   bLength                 9
   bDescriptorType         2
   wTotalLength       0x00bc
   bNumInterfaces          4
   bConfigurationValue     1
   iConfiguration          0
   bmAttributes         0xc0
     Self Powered
   MaxPower                0mA
   Interface Descriptor:
     bLength                 9
     bDescriptorType         4
     bInterfaceNumber        0
     bAlternateSetting       0
     bNumEndpoints           0
     bInterfaceClass       255 Vendor Specific Class
     bInterfaceSubClass    255 Vendor Specific Subclass
     bInterfaceProtocol      0
     iInterface              0
   Interface Descriptor:
     bLength                 9
     bDescriptorType         4
     bInterfaceNumber        1
     bAlternateSetting       0
     bNumEndpoints           0
     bInterfaceClass       255 Vendor Specific Class
     bInterfaceSubClass      2
     bInterfaceProtocol      2
     iInterface              0
     ** UNRECOGNIZED:  06 24 f1 01 00 00
   Interface Descriptor:
     bLength                 9
     bDescriptorType         4
     bInterfaceNumber        1
     bAlternateSetting       1
     bNumEndpoints           1
     bInterfaceClass       255 Vendor Specific Class
     bInterfaceSubClass      2
     bInterfaceProtocol      2
     iInterface              0
     ** UNRECOGNIZED:  07 24 01 01 00 01 00
     ** UNRECOGNIZED:  0b 24 02 01 02 04 18 01 44 ac 00
     ** UNRECOGNIZED:  06 24 f1 04 16 00
     Endpoint Descriptor:
       bLength                 7
       bDescriptorType         5
       bEndpointAddress     0x0d  EP 13 OUT
       bmAttributes            5
         Transfer Type            Isochronous
         Synch Type               Asynchronous
         Usage Type               Data
       wMaxPacketSize     0x0038  1x 56 bytes
       bInterval               1
   Interface Descriptor:
     bLength                 9
     bDescriptorType         4
     bInterfaceNumber        2
     bAlternateSetting       0
     bNumEndpoints           0
     bInterfaceClass       255 Vendor Specific Class
     bInterfaceSubClass      2
     bInterfaceProtocol      1
     iInterface              0
   Interface Descriptor:
     bLength                 9
     bDescriptorType         4
     bInterfaceNumber        2
     bAlternateSetting       1
     bNumEndpoints           1
     bInterfaceClass       255 Vendor Specific Class
     bInterfaceSubClass      2
     bInterfaceProtocol      1
     iInterface              0
     ** UNRECOGNIZED:  07 24 01 07 00 01 00
     ** UNRECOGNIZED:  0b 24 02 01 02 04 18 01 44 ac 00
     ** UNRECOGNIZED:  06 24 f1 04 16 00
     Endpoint Descriptor:
       bLength                 7
       bDescriptorType         5
       bEndpointAddress     0x8e  EP 14 IN
       bmAttributes           37
         Transfer Type            Isochronous
         Synch Type               Asynchronous
         Usage Type               Implicit feedback Data
       wMaxPacketSize     0x0038  1x 56 bytes
       bInterval               1
   Interface Descriptor:
     bLength                 9
     bDescriptorType         4
     bInterfaceNumber        3
     bAlternateSetting       0
     bNumEndpoints           2
     bInterfaceClass       255 Vendor Specific Class
     bInterfaceSubClass      3
     bInterfaceProtocol      0
     iInterface              0
     ** UNRECOGNIZED:  06 24 f1 02 01 01
     Endpoint Descriptor:
       bLength                 7
       bDescriptorType         5
       bEndpointAddress     0x03  EP 3 OUT
       bmAttributes            2
         Transfer Type            Bulk
         Synch Type               None
         Usage Type               Data
       wMaxPacketSize     0x0200  1x 512 bytes
       bInterval               1
     Endpoint Descriptor:
       bLength                 7
       bDescriptorType         5
       bEndpointAddress     0x84  EP 4 IN
       bmAttributes            2
         Transfer Type            Bulk
         Synch Type               None
         Usage Type               Data
       wMaxPacketSize     0x0200  1x 512 bytes
       bInterval               0
   Interface Descriptor:
     bLength                 9
     bDescriptorType         4
     bInterfaceNumber        3
     bAlternateSetting       1
     bNumEndpoints           2
     bInterfaceClass       255 Vendor Specific Class
     bInterfaceSubClass      3
     bInterfaceProtocol      0
     iInterface              0
     Endpoint Descriptor:
       bLength                 7
       bDescriptorType         5
       bEndpointAddress     0x03  EP 3 OUT
       bmAttributes            3
         Transfer Type            Interrupt
         Synch Type               None
         Usage Type               Data
       wMaxPacketSize     0x0200  1x 512 bytes
       bInterval               4
     Endpoint Descriptor:
       bLength                 7
       bDescriptorType         5
       bEndpointAddress     0x85  EP 5 IN
       bmAttributes            3
         Transfer Type            Interrupt
         Synch Type               None
         Usage Type               Data
       wMaxPacketSize     0x0200  1x 512 bytes
       bInterval               4
Device Qualifier (for other device speed):
 bLength                10
 bDescriptorType         6
 bcdUSB               2.00
 bDeviceClass          255 Vendor Specific Class
 bDeviceSubClass         0
 bDeviceProtocol       255
 bMaxPacketSize0        64
 bNumConfigurations      1
can't get debug descriptor: Resource temporarily unavailable
Device Status:     0x0001
 Self Powered


-- 
Keith A Milner

Re: [alsa-devel] [PATCH] ALSA: usb-audio: Disable quirks for BOSS Katana amplifiers

[Mike Oliphant]

Hi Keith,

The lsusb output just shows that the endpoint is there, but not that it is
getting connected when the device is initialized. Can you check dmesg
output when you use the device for playback?

This is what I see from dmesg when the implicit feedback endpoint is being
used:

[   26.787360] usb 1-1.1: setting usb interface 1:1
[   26.787367] Creating new playback data endpoint #d
[   26.787375] Creating new capture data endpoint #8e
[   26.787678] usb 1-1.1: Setting params for ep #d (type 0, 12 urbs), ret=0
[   26.787685] usb 1-1.1: match_endpoint_audioformats: (fmt @6bc43c84)
score 2
[   26.787745] usb 1-1.1: Setting params for ep #8e (type 0, 12 urbs), ret=0
[   26.787751] usb 1-1.1: Starting data EP @a14130b5
[   26.788420] usb 1-1.1: Starting sync EP @720fb7cf

Note the "Starting sync EP".

Mike

On Wed, Oct 14, 2020 at 9:35 AM Mailing Lists <maillist@superlative.org>
wrote:

> On Wed, 14 Oct 2020 at 17:12, Mike Oliphant <oliphant@nostatic.org> wrote:
>
>> Keith - are you getting an implicit feedback endpoint created when you
>> run with the patch?
>>
>
> Hi Mike,
>
> It appears that I do. For reference I'm on kernel 5.4.0-51:
>
> Bus 001 Device 007: ID 0582:01d6 Roland Corp. GT-1
> Device Descriptor:
>  bLength                18
>  bDescriptorType         1
>  bcdUSB               2.00
>  bDeviceClass          255 Vendor Specific Class
>  bDeviceSubClass         0
>  bDeviceProtocol       255
>  bMaxPacketSize0        64
>  idVendor           0x0582 Roland Corp.
>  idProduct          0x01d6
>  bcdDevice            0.00
>  iManufacturer           1 BOSS
>  iProduct                2 GT-1
>  iSerial                 0
>  bNumConfigurations      1
>  Configuration Descriptor:
>    bLength                 9
>    bDescriptorType         2
>    wTotalLength       0x00bc
>    bNumInterfaces          4
>    bConfigurationValue     1
>    iConfiguration          0
>    bmAttributes         0xc0
>      Self Powered
>    MaxPower                0mA
>    Interface Descriptor:
>      bLength                 9
>      bDescriptorType         4
>      bInterfaceNumber        0
>      bAlternateSetting       0
>      bNumEndpoints           0
>      bInterfaceClass       255 Vendor Specific Class
>      bInterfaceSubClass    255 Vendor Specific Subclass
>      bInterfaceProtocol      0
>      iInterface              0
>    Interface Descriptor:
>      bLength                 9
>      bDescriptorType         4
>      bInterfaceNumber        1
>      bAlternateSetting       0
>      bNumEndpoints           0
>      bInterfaceClass       255 Vendor Specific Class
>      bInterfaceSubClass      2
>      bInterfaceProtocol      2
>      iInterface              0
>      ** UNRECOGNIZED:  06 24 f1 01 00 00
>    Interface Descriptor:
>      bLength                 9
>      bDescriptorType         4
>      bInterfaceNumber        1
>      bAlternateSetting       1
>      bNumEndpoints           1
>      bInterfaceClass       255 Vendor Specific Class
>      bInterfaceSubClass      2
>      bInterfaceProtocol      2
>      iInterface              0
>      ** UNRECOGNIZED:  07 24 01 01 00 01 00
>      ** UNRECOGNIZED:  0b 24 02 01 02 04 18 01 44 ac 00
>      ** UNRECOGNIZED:  06 24 f1 04 16 00
>      Endpoint Descriptor:
>        bLength                 7
>        bDescriptorType         5
>        bEndpointAddress     0x0d  EP 13 OUT
>        bmAttributes            5
>          Transfer Type            Isochronous
>          Synch Type               Asynchronous
>          Usage Type               Data
>        wMaxPacketSize     0x0038  1x 56 bytes
>        bInterval               1
>    Interface Descriptor:
>      bLength                 9
>      bDescriptorType         4
>      bInterfaceNumber        2
>      bAlternateSetting       0
>      bNumEndpoints           0
>      bInterfaceClass       255 Vendor Specific Class
>      bInterfaceSubClass      2
>      bInterfaceProtocol      1
>      iInterface              0
>    Interface Descriptor:
>      bLength                 9
>      bDescriptorType         4
>      bInterfaceNumber        2
>      bAlternateSetting       1
>      bNumEndpoints           1
>      bInterfaceClass       255 Vendor Specific Class
>      bInterfaceSubClass      2
>      bInterfaceProtocol      1
>      iInterface              0
>      ** UNRECOGNIZED:  07 24 01 07 00 01 00
>      ** UNRECOGNIZED:  0b 24 02 01 02 04 18 01 44 ac 00
>      ** UNRECOGNIZED:  06 24 f1 04 16 00
>      Endpoint Descriptor:
>        bLength                 7
>        bDescriptorType         5
>        bEndpointAddress     0x8e  EP 14 IN
>        bmAttributes           37
>          Transfer Type            Isochronous
>          Synch Type               Asynchronous
>          Usage Type               Implicit feedback Data
>        wMaxPacketSize     0x0038  1x 56 bytes
>        bInterval               1
>    Interface Descriptor:
>      bLength                 9
>      bDescriptorType         4
>      bInterfaceNumber        3
>      bAlternateSetting       0
>      bNumEndpoints           2
>      bInterfaceClass       255 Vendor Specific Class
>      bInterfaceSubClass      3
>      bInterfaceProtocol      0
>      iInterface              0
>      ** UNRECOGNIZED:  06 24 f1 02 01 01
>      Endpoint Descriptor:
>        bLength                 7
>        bDescriptorType         5
>        bEndpointAddress     0x03  EP 3 OUT
>        bmAttributes            2
>          Transfer Type            Bulk
>          Synch Type               None
>          Usage Type               Data
>        wMaxPacketSize     0x0200  1x 512 bytes
>        bInterval               1
>      Endpoint Descriptor:
>        bLength                 7
>        bDescriptorType         5
>        bEndpointAddress     0x84  EP 4 IN
>        bmAttributes            2
>          Transfer Type            Bulk
>          Synch Type               None
>          Usage Type               Data
>        wMaxPacketSize     0x0200  1x 512 bytes
>        bInterval               0
>    Interface Descriptor:
>      bLength                 9
>      bDescriptorType         4
>      bInterfaceNumber        3
>      bAlternateSetting       1
>      bNumEndpoints           2
>      bInterfaceClass       255 Vendor Specific Class
>      bInterfaceSubClass      3
>      bInterfaceProtocol      0
>      iInterface              0
>      Endpoint Descriptor:
>        bLength                 7
>        bDescriptorType         5
>        bEndpointAddress     0x03  EP 3 OUT
>        bmAttributes            3
>          Transfer Type            Interrupt
>          Synch Type               None
>          Usage Type               Data
>        wMaxPacketSize     0x0200  1x 512 bytes
>        bInterval               4
>      Endpoint Descriptor:
>        bLength                 7
>        bDescriptorType         5
>        bEndpointAddress     0x85  EP 5 IN
>        bmAttributes            3
>          Transfer Type            Interrupt
>          Synch Type               None
>          Usage Type               Data
>        wMaxPacketSize     0x0200  1x 512 bytes
>        bInterval               4
> Device Qualifier (for other device speed):
>  bLength                10
>  bDescriptorType         6
>  bcdUSB               2.00
>  bDeviceClass          255 Vendor Specific Class
>  bDeviceSubClass         0
>  bDeviceProtocol       255
>  bMaxPacketSize0        64
>  bNumConfigurations      1
> can't get debug descriptor: Resource temporarily unavailable
> Device Status:     0x0001
>  Self Powered
>
>
> --
> Keith A Milner
>

Re: [alsa-devel] [PATCH] ALSA: usb-audio: Disable quirks for BOSS Katana amplifiers

[Mailing Lists]

Hi Mike,
I'm getting this:

[Oct14 18:21] snd_usb_audio:set_format: usb 1-4: setting usb interface 1:1
[  +0.000003] snd_usb_audio:snd_usb_add_endpoint: usb 1-4: Re-using EP d in
iface 1,1 @00000000d0aa6911
[  +0.000018] snd_usb_audio:snd_usb_endpoint_set_params: usb 1-4: Setting
params for ep #d (type 0, 3 urbs), ret=0
[  +0.000002] snd_usb_audio:start_endpoints: usb 1-4: Starting data EP
@00000000d0aa6911

Cheers,

Keith

On Wed, 14 Oct 2020 at 17:46, Mike Oliphant <oliphant@nostatic.org> wrote:

> Hi Keith,
>
> The lsusb output just shows that the endpoint is there, but not that it is
> getting connected when the device is initialized. Can you check dmesg
> output when you use the device for playback?
>
> This is what I see from dmesg when the implicit feedback endpoint is being
> used:
>
> [   26.787360] usb 1-1.1: setting usb interface 1:1
> [   26.787367] Creating new playback data endpoint #d
> [   26.787375] Creating new capture data endpoint #8e
> [   26.787678] usb 1-1.1: Setting params for ep #d (type 0, 12 urbs), ret=0
> [   26.787685] usb 1-1.1: match_endpoint_audioformats: (fmt @6bc43c84)
> score 2
> [   26.787745] usb 1-1.1: Setting params for ep #8e (type 0, 12 urbs),
> ret=0
> [   26.787751] usb 1-1.1: Starting data EP @a14130b5
> [   26.788420] usb 1-1.1: Starting sync EP @720fb7cf
>
> Note the "Starting sync EP".
>
> Mike
>
> On Wed, Oct 14, 2020 at 9:35 AM Mailing Lists <maillist@superlative.org>
> wrote:
>
>> On Wed, 14 Oct 2020 at 17:12, Mike Oliphant <oliphant@nostatic.org>
>> wrote:
>>
>>> Keith - are you getting an implicit feedback endpoint created when you
>>> run with the patch?
>>>
>>
>> Hi Mike,
>>
>> It appears that I do. For reference I'm on kernel 5.4.0-51:
>>
>> Bus 001 Device 007: ID 0582:01d6 Roland Corp. GT-1
>> Device Descriptor:
>>  bLength                18
>>  bDescriptorType         1
>>  bcdUSB               2.00
>>  bDeviceClass          255 Vendor Specific Class
>>  bDeviceSubClass         0
>>  bDeviceProtocol       255
>>  bMaxPacketSize0        64
>>  idVendor           0x0582 Roland Corp.
>>  idProduct          0x01d6
>>  bcdDevice            0.00
>>  iManufacturer           1 BOSS
>>  iProduct                2 GT-1
>>  iSerial                 0
>>  bNumConfigurations      1
>>  Configuration Descriptor:
>>    bLength                 9
>>    bDescriptorType         2
>>    wTotalLength       0x00bc
>>    bNumInterfaces          4
>>    bConfigurationValue     1
>>    iConfiguration          0
>>    bmAttributes         0xc0
>>      Self Powered
>>    MaxPower                0mA
>>    Interface Descriptor:
>>      bLength                 9
>>      bDescriptorType         4
>>      bInterfaceNumber        0
>>      bAlternateSetting       0
>>      bNumEndpoints           0
>>      bInterfaceClass       255 Vendor Specific Class
>>      bInterfaceSubClass    255 Vendor Specific Subclass
>>      bInterfaceProtocol      0
>>      iInterface              0
>>    Interface Descriptor:
>>      bLength                 9
>>      bDescriptorType         4
>>      bInterfaceNumber        1
>>      bAlternateSetting       0
>>      bNumEndpoints           0
>>      bInterfaceClass       255 Vendor Specific Class
>>      bInterfaceSubClass      2
>>      bInterfaceProtocol      2
>>      iInterface              0
>>      ** UNRECOGNIZED:  06 24 f1 01 00 00
>>    Interface Descriptor:
>>      bLength                 9
>>      bDescriptorType         4
>>      bInterfaceNumber        1
>>      bAlternateSetting       1
>>      bNumEndpoints           1
>>      bInterfaceClass       255 Vendor Specific Class
>>      bInterfaceSubClass      2
>>      bInterfaceProtocol      2
>>      iInterface              0
>>      ** UNRECOGNIZED:  07 24 01 01 00 01 00
>>      ** UNRECOGNIZED:  0b 24 02 01 02 04 18 01 44 ac 00
>>      ** UNRECOGNIZED:  06 24 f1 04 16 00
>>      Endpoint Descriptor:
>>        bLength                 7
>>        bDescriptorType         5
>>        bEndpointAddress     0x0d  EP 13 OUT
>>        bmAttributes            5
>>          Transfer Type            Isochronous
>>          Synch Type               Asynchronous
>>          Usage Type               Data
>>        wMaxPacketSize     0x0038  1x 56 bytes
>>        bInterval               1
>>    Interface Descriptor:
>>      bLength                 9
>>      bDescriptorType         4
>>      bInterfaceNumber        2
>>      bAlternateSetting       0
>>      bNumEndpoints           0
>>      bInterfaceClass       255 Vendor Specific Class
>>      bInterfaceSubClass      2
>>      bInterfaceProtocol      1
>>      iInterface              0
>>    Interface Descriptor:
>>      bLength                 9
>>      bDescriptorType         4
>>      bInterfaceNumber        2
>>      bAlternateSetting       1
>>      bNumEndpoints           1
>>      bInterfaceClass       255 Vendor Specific Class
>>      bInterfaceSubClass      2
>>      bInterfaceProtocol      1
>>      iInterface              0
>>      ** UNRECOGNIZED:  07 24 01 07 00 01 00
>>      ** UNRECOGNIZED:  0b 24 02 01 02 04 18 01 44 ac 00
>>      ** UNRECOGNIZED:  06 24 f1 04 16 00
>>      Endpoint Descriptor:
>>        bLength                 7
>>        bDescriptorType         5
>>        bEndpointAddress     0x8e  EP 14 IN
>>        bmAttributes           37
>>          Transfer Type            Isochronous
>>          Synch Type               Asynchronous
>>          Usage Type               Implicit feedback Data
>>        wMaxPacketSize     0x0038  1x 56 bytes
>>        bInterval               1
>>    Interface Descriptor:
>>      bLength                 9
>>      bDescriptorType         4
>>      bInterfaceNumber        3
>>      bAlternateSetting       0
>>      bNumEndpoints           2
>>      bInterfaceClass       255 Vendor Specific Class
>>      bInterfaceSubClass      3
>>      bInterfaceProtocol      0
>>      iInterface              0
>>      ** UNRECOGNIZED:  06 24 f1 02 01 01
>>      Endpoint Descriptor:
>>        bLength                 7
>>        bDescriptorType         5
>>        bEndpointAddress     0x03  EP 3 OUT
>>        bmAttributes            2
>>          Transfer Type            Bulk
>>          Synch Type               None
>>          Usage Type               Data
>>        wMaxPacketSize     0x0200  1x 512 bytes
>>        bInterval               1
>>      Endpoint Descriptor:
>>        bLength                 7
>>        bDescriptorType         5
>>        bEndpointAddress     0x84  EP 4 IN
>>        bmAttributes            2
>>          Transfer Type            Bulk
>>          Synch Type               None
>>          Usage Type               Data
>>        wMaxPacketSize     0x0200  1x 512 bytes
>>        bInterval               0
>>    Interface Descriptor:
>>      bLength                 9
>>      bDescriptorType         4
>>      bInterfaceNumber        3
>>      bAlternateSetting       1
>>      bNumEndpoints           2
>>      bInterfaceClass       255 Vendor Specific Class
>>      bInterfaceSubClass      3
>>      bInterfaceProtocol      0
>>      iInterface              0
>>      Endpoint Descriptor:
>>        bLength                 7
>>        bDescriptorType         5
>>        bEndpointAddress     0x03  EP 3 OUT
>>        bmAttributes            3
>>          Transfer Type            Interrupt
>>          Synch Type               None
>>          Usage Type               Data
>>        wMaxPacketSize     0x0200  1x 512 bytes
>>        bInterval               4
>>      Endpoint Descriptor:
>>        bLength                 7
>>        bDescriptorType         5
>>        bEndpointAddress     0x85  EP 5 IN
>>        bmAttributes            3
>>          Transfer Type            Interrupt
>>          Synch Type               None
>>          Usage Type               Data
>>        wMaxPacketSize     0x0200  1x 512 bytes
>>        bInterval               4
>> Device Qualifier (for other device speed):
>>  bLength                10
>>  bDescriptorType         6
>>  bcdUSB               2.00
>>  bDeviceClass          255 Vendor Specific Class
>>  bDeviceSubClass         0
>>  bDeviceProtocol       255
>>  bMaxPacketSize0        64
>>  bNumConfigurations      1
>> can't get debug descriptor: Resource temporarily unavailable
>> Device Status:     0x0001
>>  Self Powered
>>
>>
>> --
>> Keith A Milner
>>
>

-- 
-- 
Keith A Milner

Re: [alsa-devel] [PATCH] ALSA: usb-audio: Disable quirks for BOSS Katana amplifiers

[Mike Oliphant]

That's also what I see from dmesg when I use the quirk device ID patch. I'm
pretty sure it means that implicit feedback is not being enabled for your
device.

Since these devices are designed to work with implicit feedback, the ideal
solution would be to have them work by using it, rather than disabling it.

That said, patching the quirk code with the extra device IDs would make it
so they at least produce output...

The "fix" I'm currently using (linked to in my first response) makes the
implicit feedback code not wait to send data until it has received some. It
works perfectly for me, but success has been mixed for others so I didn't
feel comfortable submitting it as a patch.

FYI, I did a little write-up here:

http://blog.nostatic.org/2020/01/getting-boss-gt-1-effects-processor-to.html

It outlines my struggle with this issue - from trying the quirk ID patch,
to messing with the sample rate, and finally to modifying the implicit
feedback behavior.

Mike

On Wed, Oct 14, 2020 at 10:23 AM Mailing Lists <maillist@superlative.org>
wrote:

> Hi Mike,
> I'm getting this:
>
> [Oct14 18:21] snd_usb_audio:set_format: usb 1-4: setting usb interface 1:1
> [  +0.000003] snd_usb_audio:snd_usb_add_endpoint: usb 1-4: Re-using EP d
> in iface 1,1 @00000000d0aa6911
> [  +0.000018] snd_usb_audio:snd_usb_endpoint_set_params: usb 1-4: Setting
> params for ep #d (type 0, 3 urbs), ret=0
> [  +0.000002] snd_usb_audio:start_endpoints: usb 1-4: Starting data EP
> @00000000d0aa6911
>
> Cheers,
>
> Keith
>
> On Wed, 14 Oct 2020 at 17:46, Mike Oliphant <oliphant@nostatic.org> wrote:
>
>> Hi Keith,
>>
>> The lsusb output just shows that the endpoint is there, but not that it
>> is getting connected when the device is initialized. Can you check dmesg
>> output when you use the device for playback?
>>
>> This is what I see from dmesg when the implicit feedback endpoint is
>> being used:
>>
>> [   26.787360] usb 1-1.1: setting usb interface 1:1
>> [   26.787367] Creating new playback data endpoint #d
>> [   26.787375] Creating new capture data endpoint #8e
>> [   26.787678] usb 1-1.1: Setting params for ep #d (type 0, 12 urbs),
>> ret=0
>> [   26.787685] usb 1-1.1: match_endpoint_audioformats: (fmt @6bc43c84)
>> score 2
>> [   26.787745] usb 1-1.1: Setting params for ep #8e (type 0, 12 urbs),
>> ret=0
>> [   26.787751] usb 1-1.1: Starting data EP @a14130b5
>> [   26.788420] usb 1-1.1: Starting sync EP @720fb7cf
>>
>> Note the "Starting sync EP".
>>
>> Mike
>>
>> On Wed, Oct 14, 2020 at 9:35 AM Mailing Lists <maillist@superlative.org>
>> wrote:
>>
>>> On Wed, 14 Oct 2020 at 17:12, Mike Oliphant <oliphant@nostatic.org>
>>> wrote:
>>>
>>>> Keith - are you getting an implicit feedback endpoint created when you
>>>> run with the patch?
>>>>
>>>
>>> Hi Mike,
>>>
>>> It appears that I do. For reference I'm on kernel 5.4.0-51:
>>>
>>> Bus 001 Device 007: ID 0582:01d6 Roland Corp. GT-1
>>> Device Descriptor:
>>>  bLength                18
>>>  bDescriptorType         1
>>>  bcdUSB               2.00
>>>  bDeviceClass          255 Vendor Specific Class
>>>  bDeviceSubClass         0
>>>  bDeviceProtocol       255
>>>  bMaxPacketSize0        64
>>>  idVendor           0x0582 Roland Corp.
>>>  idProduct          0x01d6
>>>  bcdDevice            0.00
>>>  iManufacturer           1 BOSS
>>>  iProduct                2 GT-1
>>>  iSerial                 0
>>>  bNumConfigurations      1
>>>  Configuration Descriptor:
>>>    bLength                 9
>>>    bDescriptorType         2
>>>    wTotalLength       0x00bc
>>>    bNumInterfaces          4
>>>    bConfigurationValue     1
>>>    iConfiguration          0
>>>    bmAttributes         0xc0
>>>      Self Powered
>>>    MaxPower                0mA
>>>    Interface Descriptor:
>>>      bLength                 9
>>>      bDescriptorType         4
>>>      bInterfaceNumber        0
>>>      bAlternateSetting       0
>>>      bNumEndpoints           0
>>>      bInterfaceClass       255 Vendor Specific Class
>>>      bInterfaceSubClass    255 Vendor Specific Subclass
>>>      bInterfaceProtocol      0
>>>      iInterface              0
>>>    Interface Descriptor:
>>>      bLength                 9
>>>      bDescriptorType         4
>>>      bInterfaceNumber        1
>>>      bAlternateSetting       0
>>>      bNumEndpoints           0
>>>      bInterfaceClass       255 Vendor Specific Class
>>>      bInterfaceSubClass      2
>>>      bInterfaceProtocol      2
>>>      iInterface              0
>>>      ** UNRECOGNIZED:  06 24 f1 01 00 00
>>>    Interface Descriptor:
>>>      bLength                 9
>>>      bDescriptorType         4
>>>      bInterfaceNumber        1
>>>      bAlternateSetting       1
>>>      bNumEndpoints           1
>>>      bInterfaceClass       255 Vendor Specific Class
>>>      bInterfaceSubClass      2
>>>      bInterfaceProtocol      2
>>>      iInterface              0
>>>      ** UNRECOGNIZED:  07 24 01 01 00 01 00
>>>      ** UNRECOGNIZED:  0b 24 02 01 02 04 18 01 44 ac 00
>>>      ** UNRECOGNIZED:  06 24 f1 04 16 00
>>>      Endpoint Descriptor:
>>>        bLength                 7
>>>        bDescriptorType         5
>>>        bEndpointAddress     0x0d  EP 13 OUT
>>>        bmAttributes            5
>>>          Transfer Type            Isochronous
>>>          Synch Type               Asynchronous
>>>          Usage Type               Data
>>>        wMaxPacketSize     0x0038  1x 56 bytes
>>>        bInterval               1
>>>    Interface Descriptor:
>>>      bLength                 9
>>>      bDescriptorType         4
>>>      bInterfaceNumber        2
>>>      bAlternateSetting       0
>>>      bNumEndpoints           0
>>>      bInterfaceClass       255 Vendor Specific Class
>>>      bInterfaceSubClass      2
>>>      bInterfaceProtocol      1
>>>      iInterface              0
>>>    Interface Descriptor:
>>>      bLength                 9
>>>      bDescriptorType         4
>>>      bInterfaceNumber        2
>>>      bAlternateSetting       1
>>>      bNumEndpoints           1
>>>      bInterfaceClass       255 Vendor Specific Class
>>>      bInterfaceSubClass      2
>>>      bInterfaceProtocol      1
>>>      iInterface              0
>>>      ** UNRECOGNIZED:  07 24 01 07 00 01 00
>>>      ** UNRECOGNIZED:  0b 24 02 01 02 04 18 01 44 ac 00
>>>      ** UNRECOGNIZED:  06 24 f1 04 16 00
>>>      Endpoint Descriptor:
>>>        bLength                 7
>>>        bDescriptorType         5
>>>        bEndpointAddress     0x8e  EP 14 IN
>>>        bmAttributes           37
>>>          Transfer Type            Isochronous
>>>          Synch Type               Asynchronous
>>>          Usage Type               Implicit feedback Data
>>>        wMaxPacketSize     0x0038  1x 56 bytes
>>>        bInterval               1
>>>    Interface Descriptor:
>>>      bLength                 9
>>>      bDescriptorType         4
>>>      bInterfaceNumber        3
>>>      bAlternateSetting       0
>>>      bNumEndpoints           2
>>>      bInterfaceClass       255 Vendor Specific Class
>>>      bInterfaceSubClass      3
>>>      bInterfaceProtocol      0
>>>      iInterface              0
>>>      ** UNRECOGNIZED:  06 24 f1 02 01 01
>>>      Endpoint Descriptor:
>>>        bLength                 7
>>>        bDescriptorType         5
>>>        bEndpointAddress     0x03  EP 3 OUT
>>>        bmAttributes            2
>>>          Transfer Type            Bulk
>>>          Synch Type               None
>>>          Usage Type               Data
>>>        wMaxPacketSize     0x0200  1x 512 bytes
>>>        bInterval               1
>>>      Endpoint Descriptor:
>>>        bLength                 7
>>>        bDescriptorType         5
>>>        bEndpointAddress     0x84  EP 4 IN
>>>        bmAttributes            2
>>>          Transfer Type            Bulk
>>>          Synch Type               None
>>>          Usage Type               Data
>>>        wMaxPacketSize     0x0200  1x 512 bytes
>>>        bInterval               0
>>>    Interface Descriptor:
>>>      bLength                 9
>>>      bDescriptorType         4
>>>      bInterfaceNumber        3
>>>      bAlternateSetting       1
>>>      bNumEndpoints           2
>>>      bInterfaceClass       255 Vendor Specific Class
>>>      bInterfaceSubClass      3
>>>      bInterfaceProtocol      0
>>>      iInterface              0
>>>      Endpoint Descriptor:
>>>        bLength                 7
>>>        bDescriptorType         5
>>>        bEndpointAddress     0x03  EP 3 OUT
>>>        bmAttributes            3
>>>          Transfer Type            Interrupt
>>>          Synch Type               None
>>>          Usage Type               Data
>>>        wMaxPacketSize     0x0200  1x 512 bytes
>>>        bInterval               4
>>>      Endpoint Descriptor:
>>>        bLength                 7
>>>        bDescriptorType         5
>>>        bEndpointAddress     0x85  EP 5 IN
>>>        bmAttributes            3
>>>          Transfer Type            Interrupt
>>>          Synch Type               None
>>>          Usage Type               Data
>>>        wMaxPacketSize     0x0200  1x 512 bytes
>>>        bInterval               4
>>> Device Qualifier (for other device speed):
>>>  bLength                10
>>>  bDescriptorType         6
>>>  bcdUSB               2.00
>>>  bDeviceClass          255 Vendor Specific Class
>>>  bDeviceSubClass         0
>>>  bDeviceProtocol       255
>>>  bMaxPacketSize0        64
>>>  bNumConfigurations      1
>>> can't get debug descriptor: Resource temporarily unavailable
>>> Device Status:     0x0001
>>>  Self Powered
>>>
>>>
>>> --
>>> Keith A Milner
>>>
>>
>
> --
> --
> Keith A Milner
>

Re: [alsa-devel] [PATCH] ALSA: usb-audio: Disable quirks for BOSS Katana amplifiers

[Keith Milner]

I thought I would re-try the change you made. When I tried this last year
on my old laptop, I recall I couldn't get it working properly.

This time around it works... sort of, but isn't without some significant
issues for me. For a start, it only works in Jack. If I try to access the
alsa device directly (for instance, using ALSA mode in Ardour or using
Audacity) it doesn't work. It also fills my dmesg with error messages:

[  184.089158] usb 1-4: Unable to change format on ep #8e: already in use
[  184.089232] usb 1-4: Unable to change format on ep #8e: already in use
[  184.089401] usb 1-4: Unable to change format on ep #8e: already in use
[  184.089619] usb 1-4: Unable to change format on ep #8e: already in use

So, unfortunately, whilst it seems like it's a tactical fix for some
situations, it seems to be broken in other ways.

When I tried it on my GT-001 I got similar results, although only one
"Unable to change format on ep #8e: already in use" message this time
rather than the logs getting spammed. Interestingly, I got more xruns with
this as well.

Personally I'll be going back to how I had it before with the implicit
feedback disabled, as it's more reliable and functional for me, but it's
clear this one isn't solved yet.

Cheers,

Keith

On Wed, 14 Oct 2020 at 19:17, Mike Oliphant <oliphant@nostatic.org> wrote:

> That's also what I see from dmesg when I use the quirk device ID patch.
> I'm pretty sure it means that implicit feedback is not being enabled for
> your device.
>
> Since these devices are designed to work with implicit feedback, the ideal
> solution would be to have them work by using it, rather than disabling it.
>
> That said, patching the quirk code with the extra device IDs would make it
> so they at least produce output...
>
> The "fix" I'm currently using (linked to in my first response) makes the
> implicit feedback code not wait to send data until it has received some. It
> works perfectly for me, but success has been mixed for others so I didn't
> feel comfortable submitting it as a patch.
>
> FYI, I did a little write-up here:
>
>
> http://blog.nostatic.org/2020/01/getting-boss-gt-1-effects-processor-to.html
>
> It outlines my struggle with this issue - from trying the quirk ID patch,
> to messing with the sample rate, and finally to modifying the implicit
> feedback behavior.
>
> Mike
>
> On Wed, Oct 14, 2020 at 10:23 AM Mailing Lists <maillist@superlative.org>
> wrote:
>
>> Hi Mike,
>> I'm getting this:
>>
>> [Oct14 18:21] snd_usb_audio:set_format: usb 1-4: setting usb interface 1:1
>> [  +0.000003] snd_usb_audio:snd_usb_add_endpoint: usb 1-4: Re-using EP d
>> in iface 1,1 @00000000d0aa6911
>> [  +0.000018] snd_usb_audio:snd_usb_endpoint_set_params: usb 1-4: Setting
>> params for ep #d (type 0, 3 urbs), ret=0
>> [  +0.000002] snd_usb_audio:start_endpoints: usb 1-4: Starting data EP
>> @00000000d0aa6911
>>
>> Cheers,
>>
>> Keith
>>
>> On Wed, 14 Oct 2020 at 17:46, Mike Oliphant <oliphant@nostatic.org>
>> wrote:
>>
>>> Hi Keith,
>>>
>>> The lsusb output just shows that the endpoint is there, but not that it
>>> is getting connected when the device is initialized. Can you check dmesg
>>> output when you use the device for playback?
>>>
>>> This is what I see from dmesg when the implicit feedback endpoint is
>>> being used:
>>>
>>> [   26.787360] usb 1-1.1: setting usb interface 1:1
>>> [   26.787367] Creating new playback data endpoint #d
>>> [   26.787375] Creating new capture data endpoint #8e
>>> [   26.787678] usb 1-1.1: Setting params for ep #d (type 0, 12 urbs),
>>> ret=0
>>> [   26.787685] usb 1-1.1: match_endpoint_audioformats: (fmt @6bc43c84)
>>> score 2
>>> [   26.787745] usb 1-1.1: Setting params for ep #8e (type 0, 12 urbs),
>>> ret=0
>>> [   26.787751] usb 1-1.1: Starting data EP @a14130b5
>>> [   26.788420] usb 1-1.1: Starting sync EP @720fb7cf
>>>
>>> Note the "Starting sync EP".
>>>
>>> Mike
>>>
>>> On Wed, Oct 14, 2020 at 9:35 AM Mailing Lists <maillist@superlative.org>
>>> wrote:
>>>
>>>> On Wed, 14 Oct 2020 at 17:12, Mike Oliphant <oliphant@nostatic.org>
>>>> wrote:
>>>>
>>>>> Keith - are you getting an implicit feedback endpoint created when you
>>>>> run with the patch?
>>>>>
>>>>
>>>> Hi Mike,
>>>>
>>>> It appears that I do. For reference I'm on kernel 5.4.0-51:
>>>>
>>>> Bus 001 Device 007: ID 0582:01d6 Roland Corp. GT-1
>>>> Device Descriptor:
>>>>  bLength                18
>>>>  bDescriptorType         1
>>>>  bcdUSB               2.00
>>>>  bDeviceClass          255 Vendor Specific Class
>>>>  bDeviceSubClass         0
>>>>  bDeviceProtocol       255
>>>>  bMaxPacketSize0        64
>>>>  idVendor           0x0582 Roland Corp.
>>>>  idProduct          0x01d6
>>>>  bcdDevice            0.00
>>>>  iManufacturer           1 BOSS
>>>>  iProduct                2 GT-1
>>>>  iSerial                 0
>>>>  bNumConfigurations      1
>>>>  Configuration Descriptor:
>>>>    bLength                 9
>>>>    bDescriptorType         2
>>>>    wTotalLength       0x00bc
>>>>    bNumInterfaces          4
>>>>    bConfigurationValue     1
>>>>    iConfiguration          0
>>>>    bmAttributes         0xc0
>>>>      Self Powered
>>>>    MaxPower                0mA
>>>>    Interface Descriptor:
>>>>      bLength                 9
>>>>      bDescriptorType         4
>>>>      bInterfaceNumber        0
>>>>      bAlternateSetting       0
>>>>      bNumEndpoints           0
>>>>      bInterfaceClass       255 Vendor Specific Class
>>>>      bInterfaceSubClass    255 Vendor Specific Subclass
>>>>      bInterfaceProtocol      0
>>>>      iInterface              0
>>>>    Interface Descriptor:
>>>>      bLength                 9
>>>>      bDescriptorType         4
>>>>      bInterfaceNumber        1
>>>>      bAlternateSetting       0
>>>>      bNumEndpoints           0
>>>>      bInterfaceClass       255 Vendor Specific Class
>>>>      bInterfaceSubClass      2
>>>>      bInterfaceProtocol      2
>>>>      iInterface              0
>>>>      ** UNRECOGNIZED:  06 24 f1 01 00 00
>>>>    Interface Descriptor:
>>>>      bLength                 9
>>>>      bDescriptorType         4
>>>>      bInterfaceNumber        1
>>>>      bAlternateSetting       1
>>>>      bNumEndpoints           1
>>>>      bInterfaceClass       255 Vendor Specific Class
>>>>      bInterfaceSubClass      2
>>>>      bInterfaceProtocol      2
>>>>      iInterface              0
>>>>      ** UNRECOGNIZED:  07 24 01 01 00 01 00
>>>>      ** UNRECOGNIZED:  0b 24 02 01 02 04 18 01 44 ac 00
>>>>      ** UNRECOGNIZED:  06 24 f1 04 16 00
>>>>      Endpoint Descriptor:
>>>>        bLength                 7
>>>>        bDescriptorType         5
>>>>        bEndpointAddress     0x0d  EP 13 OUT
>>>>        bmAttributes            5
>>>>          Transfer Type            Isochronous
>>>>          Synch Type               Asynchronous
>>>>          Usage Type               Data
>>>>        wMaxPacketSize     0x0038  1x 56 bytes
>>>>        bInterval               1
>>>>    Interface Descriptor:
>>>>      bLength                 9
>>>>      bDescriptorType         4
>>>>      bInterfaceNumber        2
>>>>      bAlternateSetting       0
>>>>      bNumEndpoints           0
>>>>      bInterfaceClass       255 Vendor Specific Class
>>>>      bInterfaceSubClass      2
>>>>      bInterfaceProtocol      1
>>>>      iInterface              0
>>>>    Interface Descriptor:
>>>>      bLength                 9
>>>>      bDescriptorType         4
>>>>      bInterfaceNumber        2
>>>>      bAlternateSetting       1
>>>>      bNumEndpoints           1
>>>>      bInterfaceClass       255 Vendor Specific Class
>>>>      bInterfaceSubClass      2
>>>>      bInterfaceProtocol      1
>>>>      iInterface              0
>>>>      ** UNRECOGNIZED:  07 24 01 07 00 01 00
>>>>      ** UNRECOGNIZED:  0b 24 02 01 02 04 18 01 44 ac 00
>>>>      ** UNRECOGNIZED:  06 24 f1 04 16 00
>>>>      Endpoint Descriptor:
>>>>        bLength                 7
>>>>        bDescriptorType         5
>>>>        bEndpointAddress     0x8e  EP 14 IN
>>>>        bmAttributes           37
>>>>          Transfer Type            Isochronous
>>>>          Synch Type               Asynchronous
>>>>          Usage Type               Implicit feedback Data
>>>>        wMaxPacketSize     0x0038  1x 56 bytes
>>>>        bInterval               1
>>>>    Interface Descriptor:
>>>>      bLength                 9
>>>>      bDescriptorType         4
>>>>      bInterfaceNumber        3
>>>>      bAlternateSetting       0
>>>>      bNumEndpoints           2
>>>>      bInterfaceClass       255 Vendor Specific Class
>>>>      bInterfaceSubClass      3
>>>>      bInterfaceProtocol      0
>>>>      iInterface              0
>>>>      ** UNRECOGNIZED:  06 24 f1 02 01 01
>>>>      Endpoint Descriptor:
>>>>        bLength                 7
>>>>        bDescriptorType         5
>>>>        bEndpointAddress     0x03  EP 3 OUT
>>>>        bmAttributes            2
>>>>          Transfer Type            Bulk
>>>>          Synch Type               None
>>>>          Usage Type               Data
>>>>        wMaxPacketSize     0x0200  1x 512 bytes
>>>>        bInterval               1
>>>>      Endpoint Descriptor:
>>>>        bLength                 7
>>>>        bDescriptorType         5
>>>>        bEndpointAddress     0x84  EP 4 IN
>>>>        bmAttributes            2
>>>>          Transfer Type            Bulk
>>>>          Synch Type               None
>>>>          Usage Type               Data
>>>>        wMaxPacketSize     0x0200  1x 512 bytes
>>>>        bInterval               0
>>>>    Interface Descriptor:
>>>>      bLength                 9
>>>>      bDescriptorType         4
>>>>      bInterfaceNumber        3
>>>>      bAlternateSetting       1
>>>>      bNumEndpoints           2
>>>>      bInterfaceClass       255 Vendor Specific Class
>>>>      bInterfaceSubClass      3
>>>>      bInterfaceProtocol      0
>>>>      iInterface              0
>>>>      Endpoint Descriptor:
>>>>        bLength                 7
>>>>        bDescriptorType         5
>>>>        bEndpointAddress     0x03  EP 3 OUT
>>>>        bmAttributes            3
>>>>          Transfer Type            Interrupt
>>>>          Synch Type               None
>>>>          Usage Type               Data
>>>>        wMaxPacketSize     0x0200  1x 512 bytes
>>>>        bInterval               4
>>>>      Endpoint Descriptor:
>>>>        bLength                 7
>>>>        bDescriptorType         5
>>>>        bEndpointAddress     0x85  EP 5 IN
>>>>        bmAttributes            3
>>>>          Transfer Type            Interrupt
>>>>          Synch Type               None
>>>>          Usage Type               Data
>>>>        wMaxPacketSize     0x0200  1x 512 bytes
>>>>        bInterval               4
>>>> Device Qualifier (for other device speed):
>>>>  bLength                10
>>>>  bDescriptorType         6
>>>>  bcdUSB               2.00
>>>>  bDeviceClass          255 Vendor Specific Class
>>>>  bDeviceSubClass         0
>>>>  bDeviceProtocol       255
>>>>  bMaxPacketSize0        64
>>>>  bNumConfigurations      1
>>>> can't get debug descriptor: Resource temporarily unavailable
>>>> Device Status:     0x0001
>>>>  Self Powered
>>>>
>>>>
>>>> --
>>>> Keith A Milner
>>>>
>>>
>>
>> --
>> --
>> Keith A Milner
>>
>

-- 
-- 
Keith A Milner

Re: [alsa-devel] [PATCH] ALSA: usb-audio: Disable quirks for BOSS Katana amplifiers

[Mike Oliphant]

Yeah, I think the work-around I found is just that - a solution that works
in my particular situation, but does not resolve what seems to be a deeper
issue with implicit feedback on these devices.

I'd love to see a real fix, but I haven't had the time to dig more into the
code. It would be great to get some input from whoever wrote the implicit
feedback system in the first place.

Mike

On Wed, Oct 14, 2020 at 1:57 PM Keith Milner <maillist@superlative.org>
wrote:

> I thought I would re-try the change you made. When I tried this last year
> on my old laptop, I recall I couldn't get it working properly.
>
> This time around it works... sort of, but isn't without some significant
> issues for me. For a start, it only works in Jack. If I try to access the
> alsa device directly (for instance, using ALSA mode in Ardour or using
> Audacity) it doesn't work. It also fills my dmesg with error messages:
>
> [  184.089158] usb 1-4: Unable to change format on ep #8e: already in use
> [  184.089232] usb 1-4: Unable to change format on ep #8e: already in use
> [  184.089401] usb 1-4: Unable to change format on ep #8e: already in use
> [  184.089619] usb 1-4: Unable to change format on ep #8e: already in use
>
> So, unfortunately, whilst it seems like it's a tactical fix for some
> situations, it seems to be broken in other ways.
>
> When I tried it on my GT-001 I got similar results, although only one
> "Unable to change format on ep #8e: already in use" message this time
> rather than the logs getting spammed. Interestingly, I got more xruns with
> this as well.
>
> Personally I'll be going back to how I had it before with the implicit
> feedback disabled, as it's more reliable and functional for me, but it's
> clear this one isn't solved yet.
>
> Cheers,
>
> Keith
>
> On Wed, 14 Oct 2020 at 19:17, Mike Oliphant <oliphant@nostatic.org> wrote:
>
>> That's also what I see from dmesg when I use the quirk device ID patch.
>> I'm pretty sure it means that implicit feedback is not being enabled for
>> your device.
>>
>> Since these devices are designed to work with implicit feedback, the
>> ideal solution would be to have them work by using it, rather than
>> disabling it.
>>
>> That said, patching the quirk code with the extra device IDs would
>> make it so they at least produce output...
>>
>> The "fix" I'm currently using (linked to in my first response) makes the
>> implicit feedback code not wait to send data until it has received some. It
>> works perfectly for me, but success has been mixed for others so I didn't
>> feel comfortable submitting it as a patch.
>>
>> FYI, I did a little write-up here:
>>
>>
>> http://blog.nostatic.org/2020/01/getting-boss-gt-1-effects-processor-to.html
>>
>> It outlines my struggle with this issue - from trying the quirk ID patch,
>> to messing with the sample rate, and finally to modifying the implicit
>> feedback behavior.
>>
>> Mike
>>
>> On Wed, Oct 14, 2020 at 10:23 AM Mailing Lists <maillist@superlative.org>
>> wrote:
>>
>>> Hi Mike,
>>> I'm getting this:
>>>
>>> [Oct14 18:21] snd_usb_audio:set_format: usb 1-4: setting usb interface
>>> 1:1
>>> [  +0.000003] snd_usb_audio:snd_usb_add_endpoint: usb 1-4: Re-using EP d
>>> in iface 1,1 @00000000d0aa6911
>>> [  +0.000018] snd_usb_audio:snd_usb_endpoint_set_params: usb 1-4:
>>> Setting params for ep #d (type 0, 3 urbs), ret=0
>>> [  +0.000002] snd_usb_audio:start_endpoints: usb 1-4: Starting data EP
>>> @00000000d0aa6911
>>>
>>> Cheers,
>>>
>>> Keith
>>>
>>> On Wed, 14 Oct 2020 at 17:46, Mike Oliphant <oliphant@nostatic.org>
>>> wrote:
>>>
>>>> Hi Keith,
>>>>
>>>> The lsusb output just shows that the endpoint is there, but not that it
>>>> is getting connected when the device is initialized. Can you check dmesg
>>>> output when you use the device for playback?
>>>>
>>>> This is what I see from dmesg when the implicit feedback endpoint is
>>>> being used:
>>>>
>>>> [   26.787360] usb 1-1.1: setting usb interface 1:1
>>>> [   26.787367] Creating new playback data endpoint #d
>>>> [   26.787375] Creating new capture data endpoint #8e
>>>> [   26.787678] usb 1-1.1: Setting params for ep #d (type 0, 12 urbs),
>>>> ret=0
>>>> [   26.787685] usb 1-1.1: match_endpoint_audioformats: (fmt @6bc43c84)
>>>> score 2
>>>> [   26.787745] usb 1-1.1: Setting params for ep #8e (type 0, 12 urbs),
>>>> ret=0
>>>> [   26.787751] usb 1-1.1: Starting data EP @a14130b5
>>>> [   26.788420] usb 1-1.1: Starting sync EP @720fb7cf
>>>>
>>>> Note the "Starting sync EP".
>>>>
>>>> Mike
>>>>
>>>> On Wed, Oct 14, 2020 at 9:35 AM Mailing Lists <maillist@superlative.org>
>>>> wrote:
>>>>
>>>>> On Wed, 14 Oct 2020 at 17:12, Mike Oliphant <oliphant@nostatic.org>
>>>>> wrote:
>>>>>
>>>>>> Keith - are you getting an implicit feedback endpoint created when
>>>>>> you run with the patch?
>>>>>>
>>>>>
>>>>> Hi Mike,
>>>>>
>>>>> It appears that I do. For reference I'm on kernel 5.4.0-51:
>>>>>
>>>>> Bus 001 Device 007: ID 0582:01d6 Roland Corp. GT-1
>>>>> Device Descriptor:
>>>>>  bLength                18
>>>>>  bDescriptorType         1
>>>>>  bcdUSB               2.00
>>>>>  bDeviceClass          255 Vendor Specific Class
>>>>>  bDeviceSubClass         0
>>>>>  bDeviceProtocol       255
>>>>>  bMaxPacketSize0        64
>>>>>  idVendor           0x0582 Roland Corp.
>>>>>  idProduct          0x01d6
>>>>>  bcdDevice            0.00
>>>>>  iManufacturer           1 BOSS
>>>>>  iProduct                2 GT-1
>>>>>  iSerial                 0
>>>>>  bNumConfigurations      1
>>>>>  Configuration Descriptor:
>>>>>    bLength                 9
>>>>>    bDescriptorType         2
>>>>>    wTotalLength       0x00bc
>>>>>    bNumInterfaces          4
>>>>>    bConfigurationValue     1
>>>>>    iConfiguration          0
>>>>>    bmAttributes         0xc0
>>>>>      Self Powered
>>>>>    MaxPower                0mA
>>>>>    Interface Descriptor:
>>>>>      bLength                 9
>>>>>      bDescriptorType         4
>>>>>      bInterfaceNumber        0
>>>>>      bAlternateSetting       0
>>>>>      bNumEndpoints           0
>>>>>      bInterfaceClass       255 Vendor Specific Class
>>>>>      bInterfaceSubClass    255 Vendor Specific Subclass
>>>>>      bInterfaceProtocol      0
>>>>>      iInterface              0
>>>>>    Interface Descriptor:
>>>>>      bLength                 9
>>>>>      bDescriptorType         4
>>>>>      bInterfaceNumber        1
>>>>>      bAlternateSetting       0
>>>>>      bNumEndpoints           0
>>>>>      bInterfaceClass       255 Vendor Specific Class
>>>>>      bInterfaceSubClass      2
>>>>>      bInterfaceProtocol      2
>>>>>      iInterface              0
>>>>>      ** UNRECOGNIZED:  06 24 f1 01 00 00
>>>>>    Interface Descriptor:
>>>>>      bLength                 9
>>>>>      bDescriptorType         4
>>>>>      bInterfaceNumber        1
>>>>>      bAlternateSetting       1
>>>>>      bNumEndpoints           1
>>>>>      bInterfaceClass       255 Vendor Specific Class
>>>>>      bInterfaceSubClass      2
>>>>>      bInterfaceProtocol      2
>>>>>      iInterface              0
>>>>>      ** UNRECOGNIZED:  07 24 01 01 00 01 00
>>>>>      ** UNRECOGNIZED:  0b 24 02 01 02 04 18 01 44 ac 00
>>>>>      ** UNRECOGNIZED:  06 24 f1 04 16 00
>>>>>      Endpoint Descriptor:
>>>>>        bLength                 7
>>>>>        bDescriptorType         5
>>>>>        bEndpointAddress     0x0d  EP 13 OUT
>>>>>        bmAttributes            5
>>>>>          Transfer Type            Isochronous
>>>>>          Synch Type               Asynchronous
>>>>>          Usage Type               Data
>>>>>        wMaxPacketSize     0x0038  1x 56 bytes
>>>>>        bInterval               1
>>>>>    Interface Descriptor:
>>>>>      bLength                 9
>>>>>      bDescriptorType         4
>>>>>      bInterfaceNumber        2
>>>>>      bAlternateSetting       0
>>>>>      bNumEndpoints           0
>>>>>      bInterfaceClass       255 Vendor Specific Class
>>>>>      bInterfaceSubClass      2
>>>>>      bInterfaceProtocol      1
>>>>>      iInterface              0
>>>>>    Interface Descriptor:
>>>>>      bLength                 9
>>>>>      bDescriptorType         4
>>>>>      bInterfaceNumber        2
>>>>>      bAlternateSetting       1
>>>>>      bNumEndpoints           1
>>>>>      bInterfaceClass       255 Vendor Specific Class
>>>>>      bInterfaceSubClass      2
>>>>>      bInterfaceProtocol      1
>>>>>      iInterface              0
>>>>>      ** UNRECOGNIZED:  07 24 01 07 00 01 00
>>>>>      ** UNRECOGNIZED:  0b 24 02 01 02 04 18 01 44 ac 00
>>>>>      ** UNRECOGNIZED:  06 24 f1 04 16 00
>>>>>      Endpoint Descriptor:
>>>>>        bLength                 7
>>>>>        bDescriptorType         5
>>>>>        bEndpointAddress     0x8e  EP 14 IN
>>>>>        bmAttributes           37
>>>>>          Transfer Type            Isochronous
>>>>>          Synch Type               Asynchronous
>>>>>          Usage Type               Implicit feedback Data
>>>>>        wMaxPacketSize     0x0038  1x 56 bytes
>>>>>        bInterval               1
>>>>>    Interface Descriptor:
>>>>>      bLength                 9
>>>>>      bDescriptorType         4
>>>>>      bInterfaceNumber        3
>>>>>      bAlternateSetting       0
>>>>>      bNumEndpoints           2
>>>>>      bInterfaceClass       255 Vendor Specific Class
>>>>>      bInterfaceSubClass      3
>>>>>      bInterfaceProtocol      0
>>>>>      iInterface              0
>>>>>      ** UNRECOGNIZED:  06 24 f1 02 01 01
>>>>>      Endpoint Descriptor:
>>>>>        bLength                 7
>>>>>        bDescriptorType         5
>>>>>        bEndpointAddress     0x03  EP 3 OUT
>>>>>        bmAttributes            2
>>>>>          Transfer Type            Bulk
>>>>>          Synch Type               None
>>>>>          Usage Type               Data
>>>>>        wMaxPacketSize     0x0200  1x 512 bytes
>>>>>        bInterval               1
>>>>>      Endpoint Descriptor:
>>>>>        bLength                 7
>>>>>        bDescriptorType         5
>>>>>        bEndpointAddress     0x84  EP 4 IN
>>>>>        bmAttributes            2
>>>>>          Transfer Type            Bulk
>>>>>          Synch Type               None
>>>>>          Usage Type               Data
>>>>>        wMaxPacketSize     0x0200  1x 512 bytes
>>>>>        bInterval               0
>>>>>    Interface Descriptor:
>>>>>      bLength                 9
>>>>>      bDescriptorType         4
>>>>>      bInterfaceNumber        3
>>>>>      bAlternateSetting       1
>>>>>      bNumEndpoints           2
>>>>>      bInterfaceClass       255 Vendor Specific Class
>>>>>      bInterfaceSubClass      3
>>>>>      bInterfaceProtocol      0
>>>>>      iInterface              0
>>>>>      Endpoint Descriptor:
>>>>>        bLength                 7
>>>>>        bDescriptorType         5
>>>>>        bEndpointAddress     0x03  EP 3 OUT
>>>>>        bmAttributes            3
>>>>>          Transfer Type            Interrupt
>>>>>          Synch Type               None
>>>>>          Usage Type               Data
>>>>>        wMaxPacketSize     0x0200  1x 512 bytes
>>>>>        bInterval               4
>>>>>      Endpoint Descriptor:
>>>>>        bLength                 7
>>>>>        bDescriptorType         5
>>>>>        bEndpointAddress     0x85  EP 5 IN
>>>>>        bmAttributes            3
>>>>>          Transfer Type            Interrupt
>>>>>          Synch Type               None
>>>>>          Usage Type               Data
>>>>>        wMaxPacketSize     0x0200  1x 512 bytes
>>>>>        bInterval               4
>>>>> Device Qualifier (for other device speed):
>>>>>  bLength                10
>>>>>  bDescriptorType         6
>>>>>  bcdUSB               2.00
>>>>>  bDeviceClass          255 Vendor Specific Class
>>>>>  bDeviceSubClass         0
>>>>>  bDeviceProtocol       255
>>>>>  bMaxPacketSize0        64
>>>>>  bNumConfigurations      1
>>>>> can't get debug descriptor: Resource temporarily unavailable
>>>>> Device Status:     0x0001
>>>>>  Self Powered
>>>>>
>>>>>
>>>>> --
>>>>> Keith A Milner
>>>>>
>>>>
>>>
>>> --
>>> --
>>> Keith A Milner
>>>
>>
>
> --
> --
> Keith A Milner
>

Re: [alsa-devel] [PATCH] ALSA: usb-audio: Disable quirks for BOSS Katana amplifiers

[Takashi Iwai]

On Wed, 14 Oct 2020 23:49:25 +0200,
Mike Oliphant wrote:
> 
> Yeah, I think the work-around I found is just that - a solution that works
> in my particular situation, but does not resolve what seems to be a deeper
> issue with implicit feedback on these devices.
> 
> I'd love to see a real fix, but I haven't had the time to dig more into the
> code. It would be great to get some input from whoever wrote the implicit
> feedback system in the first place.

The already-in-use error is a long-standing problem of implicit fb
implementations.  Recently the support for full duplex was introduced
and should work in some level, but I'm afraid that it's not perfect.
In particular, it may still depend on the order of the device opens.

Unfortunately I have no hardware to test that shows the behavior, so
it's a bit tough to debug from my side.


thanks,

Takashi


> 
> Mike
> 
> On Wed, Oct 14, 2020 at 1:57 PM Keith Milner <maillist@superlative.org>
> wrote:
> 
> > I thought I would re-try the change you made. When I tried this last year
> > on my old laptop, I recall I couldn't get it working properly.
> >
> > This time around it works... sort of, but isn't without some significant
> > issues for me. For a start, it only works in Jack. If I try to access the
> > alsa device directly (for instance, using ALSA mode in Ardour or using
> > Audacity) it doesn't work. It also fills my dmesg with error messages:
> >
> > [  184.089158] usb 1-4: Unable to change format on ep #8e: already in use
> > [  184.089232] usb 1-4: Unable to change format on ep #8e: already in use
> > [  184.089401] usb 1-4: Unable to change format on ep #8e: already in use
> > [  184.089619] usb 1-4: Unable to change format on ep #8e: already in use
> >
> > So, unfortunately, whilst it seems like it's a tactical fix for some
> > situations, it seems to be broken in other ways.
> >
> > When I tried it on my GT-001 I got similar results, although only one
> > "Unable to change format on ep #8e: already in use" message this time
> > rather than the logs getting spammed. Interestingly, I got more xruns with
> > this as well.
> >
> > Personally I'll be going back to how I had it before with the implicit
> > feedback disabled, as it's more reliable and functional for me, but it's
> > clear this one isn't solved yet.
> >
> > Cheers,
> >
> > Keith
> >
> > On Wed, 14 Oct 2020 at 19:17, Mike Oliphant <oliphant@nostatic.org> wrote:
> >
> >> That's also what I see from dmesg when I use the quirk device ID patch.
> >> I'm pretty sure it means that implicit feedback is not being enabled for
> >> your device.
> >>
> >> Since these devices are designed to work with implicit feedback, the
> >> ideal solution would be to have them work by using it, rather than
> >> disabling it.
> >>
> >> That said, patching the quirk code with the extra device IDs would
> >> make it so they at least produce output...
> >>
> >> The "fix" I'm currently using (linked to in my first response) makes the
> >> implicit feedback code not wait to send data until it has received some. It
> >> works perfectly for me, but success has been mixed for others so I didn't
> >> feel comfortable submitting it as a patch.
> >>
> >> FYI, I did a little write-up here:
> >>
> >>
> >> http://blog.nostatic.org/2020/01/getting-boss-gt-1-effects-processor-to.html
> >>
> >> It outlines my struggle with this issue - from trying the quirk ID patch,
> >> to messing with the sample rate, and finally to modifying the implicit
> >> feedback behavior.
> >>
> >> Mike
> >>
> >> On Wed, Oct 14, 2020 at 10:23 AM Mailing Lists <maillist@superlative.org>
> >> wrote:
> >>
> >>> Hi Mike,
> >>> I'm getting this:
> >>>
> >>> [Oct14 18:21] snd_usb_audio:set_format: usb 1-4: setting usb interface
> >>> 1:1
> >>> [  +0.000003] snd_usb_audio:snd_usb_add_endpoint: usb 1-4: Re-using EP d
> >>> in iface 1,1 @00000000d0aa6911
> >>> [  +0.000018] snd_usb_audio:snd_usb_endpoint_set_params: usb 1-4:
> >>> Setting params for ep #d (type 0, 3 urbs), ret=0
> >>> [  +0.000002] snd_usb_audio:start_endpoints: usb 1-4: Starting data EP
> >>> @00000000d0aa6911
> >>>
> >>> Cheers,
> >>>
> >>> Keith
> >>>
> >>> On Wed, 14 Oct 2020 at 17:46, Mike Oliphant <oliphant@nostatic.org>
> >>> wrote:
> >>>
> >>>> Hi Keith,
> >>>>
> >>>> The lsusb output just shows that the endpoint is there, but not that it
> >>>> is getting connected when the device is initialized. Can you check dmesg
> >>>> output when you use the device for playback?
> >>>>
> >>>> This is what I see from dmesg when the implicit feedback endpoint is
> >>>> being used:
> >>>>
> >>>> [   26.787360] usb 1-1.1: setting usb interface 1:1
> >>>> [   26.787367] Creating new playback data endpoint #d
> >>>> [   26.787375] Creating new capture data endpoint #8e
> >>>> [   26.787678] usb 1-1.1: Setting params for ep #d (type 0, 12 urbs),
> >>>> ret=0
> >>>> [   26.787685] usb 1-1.1: match_endpoint_audioformats: (fmt @6bc43c84)
> >>>> score 2
> >>>> [   26.787745] usb 1-1.1: Setting params for ep #8e (type 0, 12 urbs),
> >>>> ret=0
> >>>> [   26.787751] usb 1-1.1: Starting data EP @a14130b5
> >>>> [   26.788420] usb 1-1.1: Starting sync EP @720fb7cf
> >>>>
> >>>> Note the "Starting sync EP".
> >>>>
> >>>> Mike
> >>>>
> >>>> On Wed, Oct 14, 2020 at 9:35 AM Mailing Lists <maillist@superlative.org>
> >>>> wrote:
> >>>>
> >>>>> On Wed, 14 Oct 2020 at 17:12, Mike Oliphant <oliphant@nostatic.org>
> >>>>> wrote:
> >>>>>
> >>>>>> Keith - are you getting an implicit feedback endpoint created when
> >>>>>> you run with the patch?
> >>>>>>
> >>>>>
> >>>>> Hi Mike,
> >>>>>
> >>>>> It appears that I do. For reference I'm on kernel 5.4.0-51:
> >>>>>
> >>>>> Bus 001 Device 007: ID 0582:01d6 Roland Corp. GT-1
> >>>>> Device Descriptor:
> >>>>>  bLength                18
> >>>>>  bDescriptorType         1
> >>>>>  bcdUSB               2.00
> >>>>>  bDeviceClass          255 Vendor Specific Class
> >>>>>  bDeviceSubClass         0
> >>>>>  bDeviceProtocol       255
> >>>>>  bMaxPacketSize0        64
> >>>>>  idVendor           0x0582 Roland Corp.
> >>>>>  idProduct          0x01d6
> >>>>>  bcdDevice            0.00
> >>>>>  iManufacturer           1 BOSS
> >>>>>  iProduct                2 GT-1
> >>>>>  iSerial                 0
> >>>>>  bNumConfigurations      1
> >>>>>  Configuration Descriptor:
> >>>>>    bLength                 9
> >>>>>    bDescriptorType         2
> >>>>>    wTotalLength       0x00bc
> >>>>>    bNumInterfaces          4
> >>>>>    bConfigurationValue     1
> >>>>>    iConfiguration          0
> >>>>>    bmAttributes         0xc0
> >>>>>      Self Powered
> >>>>>    MaxPower                0mA
> >>>>>    Interface Descriptor:
> >>>>>      bLength                 9
> >>>>>      bDescriptorType         4
> >>>>>      bInterfaceNumber        0
> >>>>>      bAlternateSetting       0
> >>>>>      bNumEndpoints           0
> >>>>>      bInterfaceClass       255 Vendor Specific Class
> >>>>>      bInterfaceSubClass    255 Vendor Specific Subclass
> >>>>>      bInterfaceProtocol      0
> >>>>>      iInterface              0
> >>>>>    Interface Descriptor:
> >>>>>      bLength                 9
> >>>>>      bDescriptorType         4
> >>>>>      bInterfaceNumber        1
> >>>>>      bAlternateSetting       0
> >>>>>      bNumEndpoints           0
> >>>>>      bInterfaceClass       255 Vendor Specific Class
> >>>>>      bInterfaceSubClass      2
> >>>>>      bInterfaceProtocol      2
> >>>>>      iInterface              0
> >>>>>      ** UNRECOGNIZED:  06 24 f1 01 00 00
> >>>>>    Interface Descriptor:
> >>>>>      bLength                 9
> >>>>>      bDescriptorType         4
> >>>>>      bInterfaceNumber        1
> >>>>>      bAlternateSetting       1
> >>>>>      bNumEndpoints           1
> >>>>>      bInterfaceClass       255 Vendor Specific Class
> >>>>>      bInterfaceSubClass      2
> >>>>>      bInterfaceProtocol      2
> >>>>>      iInterface              0
> >>>>>      ** UNRECOGNIZED:  07 24 01 01 00 01 00
> >>>>>      ** UNRECOGNIZED:  0b 24 02 01 02 04 18 01 44 ac 00
> >>>>>      ** UNRECOGNIZED:  06 24 f1 04 16 00
> >>>>>      Endpoint Descriptor:
> >>>>>        bLength                 7
> >>>>>        bDescriptorType         5
> >>>>>        bEndpointAddress     0x0d  EP 13 OUT
> >>>>>        bmAttributes            5
> >>>>>          Transfer Type            Isochronous
> >>>>>          Synch Type               Asynchronous
> >>>>>          Usage Type               Data
> >>>>>        wMaxPacketSize     0x0038  1x 56 bytes
> >>>>>        bInterval               1
> >>>>>    Interface Descriptor:
> >>>>>      bLength                 9
> >>>>>      bDescriptorType         4
> >>>>>      bInterfaceNumber        2
> >>>>>      bAlternateSetting       0
> >>>>>      bNumEndpoints           0
> >>>>>      bInterfaceClass       255 Vendor Specific Class
> >>>>>      bInterfaceSubClass      2
> >>>>>      bInterfaceProtocol      1
> >>>>>      iInterface              0
> >>>>>    Interface Descriptor:
> >>>>>      bLength                 9
> >>>>>      bDescriptorType         4
> >>>>>      bInterfaceNumber        2
> >>>>>      bAlternateSetting       1
> >>>>>      bNumEndpoints           1
> >>>>>      bInterfaceClass       255 Vendor Specific Class
> >>>>>      bInterfaceSubClass      2
> >>>>>      bInterfaceProtocol      1
> >>>>>      iInterface              0
> >>>>>      ** UNRECOGNIZED:  07 24 01 07 00 01 00
> >>>>>      ** UNRECOGNIZED:  0b 24 02 01 02 04 18 01 44 ac 00
> >>>>>      ** UNRECOGNIZED:  06 24 f1 04 16 00
> >>>>>      Endpoint Descriptor:
> >>>>>        bLength                 7
> >>>>>        bDescriptorType         5
> >>>>>        bEndpointAddress     0x8e  EP 14 IN
> >>>>>        bmAttributes           37
> >>>>>          Transfer Type            Isochronous
> >>>>>          Synch Type               Asynchronous
> >>>>>          Usage Type               Implicit feedback Data
> >>>>>        wMaxPacketSize     0x0038  1x 56 bytes
> >>>>>        bInterval               1
> >>>>>    Interface Descriptor:
> >>>>>      bLength                 9
> >>>>>      bDescriptorType         4
> >>>>>      bInterfaceNumber        3
> >>>>>      bAlternateSetting       0
> >>>>>      bNumEndpoints           2
> >>>>>      bInterfaceClass       255 Vendor Specific Class
> >>>>>      bInterfaceSubClass      3
> >>>>>      bInterfaceProtocol      0
> >>>>>      iInterface              0
> >>>>>      ** UNRECOGNIZED:  06 24 f1 02 01 01
> >>>>>      Endpoint Descriptor:
> >>>>>        bLength                 7
> >>>>>        bDescriptorType         5
> >>>>>        bEndpointAddress     0x03  EP 3 OUT
> >>>>>        bmAttributes            2
> >>>>>          Transfer Type            Bulk
> >>>>>          Synch Type               None
> >>>>>          Usage Type               Data
> >>>>>        wMaxPacketSize     0x0200  1x 512 bytes
> >>>>>        bInterval               1
> >>>>>      Endpoint Descriptor:
> >>>>>        bLength                 7
> >>>>>        bDescriptorType         5
> >>>>>        bEndpointAddress     0x84  EP 4 IN
> >>>>>        bmAttributes            2
> >>>>>          Transfer Type            Bulk
> >>>>>          Synch Type               None
> >>>>>          Usage Type               Data
> >>>>>        wMaxPacketSize     0x0200  1x 512 bytes
> >>>>>        bInterval               0
> >>>>>    Interface Descriptor:
> >>>>>      bLength                 9
> >>>>>      bDescriptorType         4
> >>>>>      bInterfaceNumber        3
> >>>>>      bAlternateSetting       1
> >>>>>      bNumEndpoints           2
> >>>>>      bInterfaceClass       255 Vendor Specific Class
> >>>>>      bInterfaceSubClass      3
> >>>>>      bInterfaceProtocol      0
> >>>>>      iInterface              0
> >>>>>      Endpoint Descriptor:
> >>>>>        bLength                 7
> >>>>>        bDescriptorType         5
> >>>>>        bEndpointAddress     0x03  EP 3 OUT
> >>>>>        bmAttributes            3
> >>>>>          Transfer Type            Interrupt
> >>>>>          Synch Type               None
> >>>>>          Usage Type               Data
> >>>>>        wMaxPacketSize     0x0200  1x 512 bytes
> >>>>>        bInterval               4
> >>>>>      Endpoint Descriptor:
> >>>>>        bLength                 7
> >>>>>        bDescriptorType         5
> >>>>>        bEndpointAddress     0x85  EP 5 IN
> >>>>>        bmAttributes            3
> >>>>>          Transfer Type            Interrupt
> >>>>>          Synch Type               None
> >>>>>          Usage Type               Data
> >>>>>        wMaxPacketSize     0x0200  1x 512 bytes
> >>>>>        bInterval               4
> >>>>> Device Qualifier (for other device speed):
> >>>>>  bLength                10
> >>>>>  bDescriptorType         6
> >>>>>  bcdUSB               2.00
> >>>>>  bDeviceClass          255 Vendor Specific Class
> >>>>>  bDeviceSubClass         0
> >>>>>  bDeviceProtocol       255
> >>>>>  bMaxPacketSize0        64
> >>>>>  bNumConfigurations      1
> >>>>> can't get debug descriptor: Resource temporarily unavailable
> >>>>> Device Status:     0x0001
> >>>>>  Self Powered
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Keith A Milner
> >>>>>
> >>>>
> >>>
> >>> --
> >>> --
> >>> Keith A Milner
> >>>
> >>
> >
> > --
> > --
> > Keith A Milner
> >
> 

Re: [alsa-devel] [PATCH] ALSA: usb-audio: Disable quirks for BOSS Katana amplifiers

[Mike Oliphant]

Thanks for the input, Takashi - and I completely understand the difficulty
in resolving problems for specific hardware that you don't have available.

Mike

On Thu, Oct 15, 2020 at 5:37 AM Takashi Iwai <tiwai@suse.de> wrote:

> On Wed, 14 Oct 2020 23:49:25 +0200,
> Mike Oliphant wrote:
> >
> > Yeah, I think the work-around I found is just that - a solution that
> works
> > in my particular situation, but does not resolve what seems to be a
> deeper
> > issue with implicit feedback on these devices.
> >
> > I'd love to see a real fix, but I haven't had the time to dig more into
> the
> > code. It would be great to get some input from whoever wrote the implicit
> > feedback system in the first place.
>
> The already-in-use error is a long-standing problem of implicit fb
> implementations.  Recently the support for full duplex was introduced
> and should work in some level, but I'm afraid that it's not perfect.
> In particular, it may still depend on the order of the device opens.
>
> Unfortunately I have no hardware to test that shows the behavior, so
> it's a bit tough to debug from my side.
>
>
> thanks,
>
> Takashi
>
>
> >
> > Mike
> >
> > On Wed, Oct 14, 2020 at 1:57 PM Keith Milner <maillist@superlative.org>
> > wrote:
> >
> > > I thought I would re-try the change you made. When I tried this last
> year
> > > on my old laptop, I recall I couldn't get it working properly.
> > >
> > > This time around it works... sort of, but isn't without some
> significant
> > > issues for me. For a start, it only works in Jack. If I try to access
> the
> > > alsa device directly (for instance, using ALSA mode in Ardour or using
> > > Audacity) it doesn't work. It also fills my dmesg with error messages:
> > >
> > > [  184.089158] usb 1-4: Unable to change format on ep #8e: already in
> use
> > > [  184.089232] usb 1-4: Unable to change format on ep #8e: already in
> use
> > > [  184.089401] usb 1-4: Unable to change format on ep #8e: already in
> use
> > > [  184.089619] usb 1-4: Unable to change format on ep #8e: already in
> use
> > >
> > > So, unfortunately, whilst it seems like it's a tactical fix for some
> > > situations, it seems to be broken in other ways.
> > >
> > > When I tried it on my GT-001 I got similar results, although only one
> > > "Unable to change format on ep #8e: already in use" message this time
> > > rather than the logs getting spammed. Interestingly, I got more xruns
> with
> > > this as well.
> > >
> > > Personally I'll be going back to how I had it before with the implicit
> > > feedback disabled, as it's more reliable and functional for me, but
> it's
> > > clear this one isn't solved yet.
> > >
> > > Cheers,
> > >
> > > Keith
> > >
> > > On Wed, 14 Oct 2020 at 19:17, Mike Oliphant <oliphant@nostatic.org>
> wrote:
> > >
> > >> That's also what I see from dmesg when I use the quirk device ID
> patch.
> > >> I'm pretty sure it means that implicit feedback is not being enabled
> for
> > >> your device.
> > >>
> > >> Since these devices are designed to work with implicit feedback, the
> > >> ideal solution would be to have them work by using it, rather than
> > >> disabling it.
> > >>
> > >> That said, patching the quirk code with the extra device IDs would
> > >> make it so they at least produce output...
> > >>
> > >> The "fix" I'm currently using (linked to in my first response) makes
> the
> > >> implicit feedback code not wait to send data until it has received
> some. It
> > >> works perfectly for me, but success has been mixed for others so I
> didn't
> > >> feel comfortable submitting it as a patch.
> > >>
> > >> FYI, I did a little write-up here:
> > >>
> > >>
> > >>
> http://blog.nostatic.org/2020/01/getting-boss-gt-1-effects-processor-to.html
> > >>
> > >> It outlines my struggle with this issue - from trying the quirk ID
> patch,
> > >> to messing with the sample rate, and finally to modifying the implicit
> > >> feedback behavior.
> > >>
> > >> Mike
> > >>
> > >> On Wed, Oct 14, 2020 at 10:23 AM Mailing Lists <
> maillist@superlative.org>
> > >> wrote:
> > >>
> > >>> Hi Mike,
> > >>> I'm getting this:
> > >>>
> > >>> [Oct14 18:21] snd_usb_audio:set_format: usb 1-4: setting usb
> interface
> > >>> 1:1
> > >>> [  +0.000003] snd_usb_audio:snd_usb_add_endpoint: usb 1-4: Re-using
> EP d
> > >>> in iface 1,1 @00000000d0aa6911
> > >>> [  +0.000018] snd_usb_audio:snd_usb_endpoint_set_params: usb 1-4:
> > >>> Setting params for ep #d (type 0, 3 urbs), ret=0
> > >>> [  +0.000002] snd_usb_audio:start_endpoints: usb 1-4: Starting data
> EP
> > >>> @00000000d0aa6911
> > >>>
> > >>> Cheers,
> > >>>
> > >>> Keith
> > >>>
> > >>> On Wed, 14 Oct 2020 at 17:46, Mike Oliphant <oliphant@nostatic.org>
> > >>> wrote:
> > >>>
> > >>>> Hi Keith,
> > >>>>
> > >>>> The lsusb output just shows that the endpoint is there, but not
> that it
> > >>>> is getting connected when the device is initialized. Can you check
> dmesg
> > >>>> output when you use the device for playback?
> > >>>>
> > >>>> This is what I see from dmesg when the implicit feedback endpoint is
> > >>>> being used:
> > >>>>
> > >>>> [   26.787360] usb 1-1.1: setting usb interface 1:1
> > >>>> [   26.787367] Creating new playback data endpoint #d
> > >>>> [   26.787375] Creating new capture data endpoint #8e
> > >>>> [   26.787678] usb 1-1.1: Setting params for ep #d (type 0, 12
> urbs),
> > >>>> ret=0
> > >>>> [   26.787685] usb 1-1.1: match_endpoint_audioformats: (fmt
> @6bc43c84)
> > >>>> score 2
> > >>>> [   26.787745] usb 1-1.1: Setting params for ep #8e (type 0, 12
> urbs),
> > >>>> ret=0
> > >>>> [   26.787751] usb 1-1.1: Starting data EP @a14130b5
> > >>>> [   26.788420] usb 1-1.1: Starting sync EP @720fb7cf
> > >>>>
> > >>>> Note the "Starting sync EP".
> > >>>>
> > >>>> Mike
> > >>>>
> > >>>> On Wed, Oct 14, 2020 at 9:35 AM Mailing Lists <
> maillist@superlative.org>
> > >>>> wrote:
> > >>>>
> > >>>>> On Wed, 14 Oct 2020 at 17:12, Mike Oliphant <oliphant@nostatic.org
> >
> > >>>>> wrote:
> > >>>>>
> > >>>>>> Keith - are you getting an implicit feedback endpoint created when
> > >>>>>> you run with the patch?
> > >>>>>>
> > >>>>>
> > >>>>> Hi Mike,
> > >>>>>
> > >>>>> It appears that I do. For reference I'm on kernel 5.4.0-51:
> > >>>>>
> > >>>>> Bus 001 Device 007: ID 0582:01d6 Roland Corp. GT-1
> > >>>>> Device Descriptor:
> > >>>>>  bLength                18
> > >>>>>  bDescriptorType         1
> > >>>>>  bcdUSB               2.00
> > >>>>>  bDeviceClass          255 Vendor Specific Class
> > >>>>>  bDeviceSubClass         0
> > >>>>>  bDeviceProtocol       255
> > >>>>>  bMaxPacketSize0        64
> > >>>>>  idVendor           0x0582 Roland Corp.
> > >>>>>  idProduct          0x01d6
> > >>>>>  bcdDevice            0.00
> > >>>>>  iManufacturer           1 BOSS
> > >>>>>  iProduct                2 GT-1
> > >>>>>  iSerial                 0
> > >>>>>  bNumConfigurations      1
> > >>>>>  Configuration Descriptor:
> > >>>>>    bLength                 9
> > >>>>>    bDescriptorType         2
> > >>>>>    wTotalLength       0x00bc
> > >>>>>    bNumInterfaces          4
> > >>>>>    bConfigurationValue     1
> > >>>>>    iConfiguration          0
> > >>>>>    bmAttributes         0xc0
> > >>>>>      Self Powered
> > >>>>>    MaxPower                0mA
> > >>>>>    Interface Descriptor:
> > >>>>>      bLength                 9
> > >>>>>      bDescriptorType         4
> > >>>>>      bInterfaceNumber        0
> > >>>>>      bAlternateSetting       0
> > >>>>>      bNumEndpoints           0
> > >>>>>      bInterfaceClass       255 Vendor Specific Class
> > >>>>>      bInterfaceSubClass    255 Vendor Specific Subclass
> > >>>>>      bInterfaceProtocol      0
> > >>>>>      iInterface              0
> > >>>>>    Interface Descriptor:
> > >>>>>      bLength                 9
> > >>>>>      bDescriptorType         4
> > >>>>>      bInterfaceNumber        1
> > >>>>>      bAlternateSetting       0
> > >>>>>      bNumEndpoints           0
> > >>>>>      bInterfaceClass       255 Vendor Specific Class
> > >>>>>      bInterfaceSubClass      2
> > >>>>>      bInterfaceProtocol      2
> > >>>>>      iInterface              0
> > >>>>>      ** UNRECOGNIZED:  06 24 f1 01 00 00
> > >>>>>    Interface Descriptor:
> > >>>>>      bLength                 9
> > >>>>>      bDescriptorType         4
> > >>>>>      bInterfaceNumber        1
> > >>>>>      bAlternateSetting       1
> > >>>>>      bNumEndpoints           1
> > >>>>>      bInterfaceClass       255 Vendor Specific Class
> > >>>>>      bInterfaceSubClass      2
> > >>>>>      bInterfaceProtocol      2
> > >>>>>      iInterface              0
> > >>>>>      ** UNRECOGNIZED:  07 24 01 01 00 01 00
> > >>>>>      ** UNRECOGNIZED:  0b 24 02 01 02 04 18 01 44 ac 00
> > >>>>>      ** UNRECOGNIZED:  06 24 f1 04 16 00
> > >>>>>      Endpoint Descriptor:
> > >>>>>        bLength                 7
> > >>>>>        bDescriptorType         5
> > >>>>>        bEndpointAddress     0x0d  EP 13 OUT
> > >>>>>        bmAttributes            5
> > >>>>>          Transfer Type            Isochronous
> > >>>>>          Synch Type               Asynchronous
> > >>>>>          Usage Type               Data
> > >>>>>        wMaxPacketSize     0x0038  1x 56 bytes
> > >>>>>        bInterval               1
> > >>>>>    Interface Descriptor:
> > >>>>>      bLength                 9
> > >>>>>      bDescriptorType         4
> > >>>>>      bInterfaceNumber        2
> > >>>>>      bAlternateSetting       0
> > >>>>>      bNumEndpoints           0
> > >>>>>      bInterfaceClass       255 Vendor Specific Class
> > >>>>>      bInterfaceSubClass      2
> > >>>>>      bInterfaceProtocol      1
> > >>>>>      iInterface              0
> > >>>>>    Interface Descriptor:
> > >>>>>      bLength                 9
> > >>>>>      bDescriptorType         4
> > >>>>>      bInterfaceNumber        2
> > >>>>>      bAlternateSetting       1
> > >>>>>      bNumEndpoints           1
> > >>>>>      bInterfaceClass       255 Vendor Specific Class
> > >>>>>      bInterfaceSubClass      2
> > >>>>>      bInterfaceProtocol      1
> > >>>>>      iInterface              0
> > >>>>>      ** UNRECOGNIZED:  07 24 01 07 00 01 00
> > >>>>>      ** UNRECOGNIZED:  0b 24 02 01 02 04 18 01 44 ac 00
> > >>>>>      ** UNRECOGNIZED:  06 24 f1 04 16 00
> > >>>>>      Endpoint Descriptor:
> > >>>>>        bLength                 7
> > >>>>>        bDescriptorType         5
> > >>>>>        bEndpointAddress     0x8e  EP 14 IN
> > >>>>>        bmAttributes           37
> > >>>>>          Transfer Type            Isochronous
> > >>>>>          Synch Type               Asynchronous
> > >>>>>          Usage Type               Implicit feedback Data
> > >>>>>        wMaxPacketSize     0x0038  1x 56 bytes
> > >>>>>        bInterval               1
> > >>>>>    Interface Descriptor:
> > >>>>>      bLength                 9
> > >>>>>      bDescriptorType         4
> > >>>>>      bInterfaceNumber        3
> > >>>>>      bAlternateSetting       0
> > >>>>>      bNumEndpoints           2
> > >>>>>      bInterfaceClass       255 Vendor Specific Class
> > >>>>>      bInterfaceSubClass      3
> > >>>>>      bInterfaceProtocol      0
> > >>>>>      iInterface              0
> > >>>>>      ** UNRECOGNIZED:  06 24 f1 02 01 01
> > >>>>>      Endpoint Descriptor:
> > >>>>>        bLength                 7
> > >>>>>        bDescriptorType         5
> > >>>>>        bEndpointAddress     0x03  EP 3 OUT
> > >>>>>        bmAttributes            2
> > >>>>>          Transfer Type            Bulk
> > >>>>>          Synch Type               None
> > >>>>>          Usage Type               Data
> > >>>>>        wMaxPacketSize     0x0200  1x 512 bytes
> > >>>>>        bInterval               1
> > >>>>>      Endpoint Descriptor:
> > >>>>>        bLength                 7
> > >>>>>        bDescriptorType         5
> > >>>>>        bEndpointAddress     0x84  EP 4 IN
> > >>>>>        bmAttributes            2
> > >>>>>          Transfer Type            Bulk
> > >>>>>          Synch Type               None
> > >>>>>          Usage Type               Data
> > >>>>>        wMaxPacketSize     0x0200  1x 512 bytes
> > >>>>>        bInterval               0
> > >>>>>    Interface Descriptor:
> > >>>>>      bLength                 9
> > >>>>>      bDescriptorType         4
> > >>>>>      bInterfaceNumber        3
> > >>>>>      bAlternateSetting       1
> > >>>>>      bNumEndpoints           2
> > >>>>>      bInterfaceClass       255 Vendor Specific Class
> > >>>>>      bInterfaceSubClass      3
> > >>>>>      bInterfaceProtocol      0
> > >>>>>      iInterface              0
> > >>>>>      Endpoint Descriptor:
> > >>>>>        bLength                 7
> > >>>>>        bDescriptorType         5
> > >>>>>        bEndpointAddress     0x03  EP 3 OUT
> > >>>>>        bmAttributes            3
> > >>>>>          Transfer Type            Interrupt
> > >>>>>          Synch Type               None
> > >>>>>          Usage Type               Data
> > >>>>>        wMaxPacketSize     0x0200  1x 512 bytes
> > >>>>>        bInterval               4
> > >>>>>      Endpoint Descriptor:
> > >>>>>        bLength                 7
> > >>>>>        bDescriptorType         5
> > >>>>>        bEndpointAddress     0x85  EP 5 IN
> > >>>>>        bmAttributes            3
> > >>>>>          Transfer Type            Interrupt
> > >>>>>          Synch Type               None
> > >>>>>          Usage Type               Data
> > >>>>>        wMaxPacketSize     0x0200  1x 512 bytes
> > >>>>>        bInterval               4
> > >>>>> Device Qualifier (for other device speed):
> > >>>>>  bLength                10
> > >>>>>  bDescriptorType         6
> > >>>>>  bcdUSB               2.00
> > >>>>>  bDeviceClass          255 Vendor Specific Class
> > >>>>>  bDeviceSubClass         0
> > >>>>>  bDeviceProtocol       255
> > >>>>>  bMaxPacketSize0        64
> > >>>>>  bNumConfigurations      1
> > >>>>> can't get debug descriptor: Resource temporarily unavailable
> > >>>>> Device Status:     0x0001
> > >>>>>  Self Powered
> > >>>>>
> > >>>>>
> > >>>>> --
> > >>>>> Keith A Milner
> > >>>>>
> > >>>>
> > >>>
> > >>> --
> > >>> --
> > >>> Keith A Milner
> > >>>
> > >>
> > >
> > > --
> > > --
> > > Keith A Milner
> > >
> >
>