ALSA: usb-audio: Disable quirks for BOSS Katana amplifiers
PATCH 1/1 ALSA: usb-audio: Disable quirks for BOSS Katana amplifiers
BOSS Katana amplifiers cannot be used for recording or playback if quirks are applied
--- sound/usb/pcm.c | 3 +++ 1 file changed, 3 insertions(+)
sound/usb/pcm.c +3 -0
@@ -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 &&
Signature · 1 line
2.20.1
Quoted 6 lines · Szabolcs Szőke
BOSS Katana amplifiers cannot be used for recording or playback if quirks are applied
Signed-off-by Szabolcs Szőke <[email protected]>
Applied now. Thanks.
Takashi
Quoted 22 lines
--- sound/usb/pcm.c | 3 +++ 1 file changed, 3 insertions(+)sound/usb/pcm.c +3
-0@@ -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 &&Signature · 1 line
2.20.1
Thank you for your help!
Den tors 17 okt. 2019 10:19Takashi Iwai <[email protected]> skrev:
Quoted 19 lines
Quoted 6 lines · Szabolcs Szőke
BOSS Katana amplifiers cannot be used for recording or playback if quirks are applied
Signed-off-by Szabolcs Szőke <[email protected]>Applied now. Thanks.
Takashi
Quoted 5 lines
--- sound/usb/pcm.c | 3 +++ 1 file changed, 3 insertions(+)
Quoted 19 lines
sound/usb/pcm.c static int set_sync_ep_implicit_fb_quirk(struct
Quoted 5 lines
sound/usb/pcm.c +0
-0@@ -348,6 +348,9 @@ static int set_sync_ep_implicit_fb_quirk(struct
snd_usb_substream*subs,Quoted 12 lines
sound/usb/pcm.c +3
-1ep =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
[email protected]
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
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
Quoted 42 lines · Takashi Iwai
Quoted 6 lines · Szabolcs Szőke
BOSS Katana amplifiers cannot be used for recording or playback if quirks are applied
Signed-off-by Szabolcs Szőke <[email protected]>Applied now. Thanks.
Takashi
sound/usb/pcm.c static int set_sync_ep_implicit_fb_quirk(struct
Quoted 10 lines
--- sound/usb/pcm.c | 3 +++ 1 file changed, 3 insertions(+)sound/usb/pcm.c +0
-0@@ -348,6 +348,9 @@ static int set_sync_ep_implicit_fb_quirk(struct
snd_usb_substream*subs,Quoted 10 lines
sound/usb/pcm.c +3
-1ep =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 && --Quoted 2 lines
2.20.1
_______________________________________________
Alsa-devel mailing list
[email protected]
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Signature · 2 lines
-- Keith A Milner
Quoted 16 lines · 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.cset_sync_ep_implicit_fb_quirk:case
USB_ID(0x0582, 0x01d8): /* BOSS Katana */
caseUSB_ID(0x0582, 0x0130): /* BOSS Micro BR-80 */
caseUSB_ID(0x0582, 0x0138): /* BOSS RC-300 */
caseUSB_ID(0x0582, 0x01d6): /* BOSS GT-1 */
caseUSB_ID(0x0582, 0x01e5): /* BOSS GT-001 */
/* BOSS Katana amplifiers and many other newer BOSS devices do not need quirks */
Quoted 7 lines
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.cor 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
Thanks for the response Takashi,
How should this be distinguishing between Roland and BOSS? They both have the vendor ID 0x0582.
Cheers,
Keith
Quoted 76 lines · Takashi Iwai
Quoted 2 lines · Mailing Lists
Following up on this, it appears there are a bunch of the
newer-generation
Quoted 4 lines
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
Quoted 8 lines
the following change to the code in
pcm.cset_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
Quoted 6 lines
*/
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.corwould it
Quoted 3 lines
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,
structusb_device*dev, structusb_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
Signature · 2 lines
-- Keith A Milner
Quoted 5 lines · Mailing Lists
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
Quoted 89 lines
Cheers,
Keith
On Wed, 14 Oct 2020 at 14:09, Takashi Iwai <[email protected]> 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
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
Quoted 120 lines · Takashi Iwai
Quoted 4 lines · Mailing Lists
Thanks for the response Takashi,
How should this be distinguishing between Roland and BOSS? They both
have the
Quoted 1 line
vendor ID
0x0582.Ah, right, I missed that point :-<
So the question would be rather how to detect BOSS devices effectively...
thanks,
Takashi
Quoted 7 lines
Cheers,
Keith
On Wed, 14 Oct 2020 at 14:09, Takashi Iwai <[email protected]> wrote:
Quoted 8 lines
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, andothers
Quoted 2 lines
have
> reported the RC-300 as working with similar modifications. I havebeen
Quoted 2 lines
using
> the following change to the code inpcm.c
set_sync_ep_implicit_fb_quirk:Quoted 7 lines
Quoted 7 lines
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
Quoted 4 lines
quirks > */ > > There's probably others too, such as the GT-100 (I believe theGT-001
Quoted 4 lines
and
> GT-100 have similar hardware).
>
> My question is, should this just be submitted as a patch topcm.cor
Quoted 6 lines
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
Quoted 6 lines
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,
Quoted 2 lines
struct
usb_device*dev, struct
usb_interface_descriptorQuoted 8 lines
*altsd, unsigned int attr) { .... switch (subs->stream->chip->usb_id) { .... case USB_ID(0x0582, 0x01d8): /* BOSS Katana */ /* BOSS Katana amplifiers do not need quirks */Quoted 8 lines
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
Quoted 2 lines
*/ && search_roland_implicit_fb(dev, altsd->bInterfaceNumber +1,
Quoted 23 lines
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
Signature · 2 lines
-- Keith A Milner
Quoted 8 lines · 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.
Quoted 8 lines
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
Quoted 133 lines
Cheers,
Keith
On Wed, 14 Oct 2020 at 14:47, Takashi Iwai <[email protected]> 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 <[email protected]> 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 inpcm.cset_sync_ep_implicit_fb_quirk:
> >
> > caseUSB_ID(0x0582, 0x01d8): /* BOSS Katana */
> > caseUSB_ID(0x0582, 0x0130): /* BOSS Micro BR-80 */ > > caseUSB_ID(0x0582, 0x0138): /* BOSS RC-300 */
> > caseUSB_ID(0x0582, 0x01d6): /* BOSS GT-1 */
> > caseUSB_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 topcm.cor
> 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(structsnd_usb_substream*subs,
> structusb_device*dev, > structusb_interface_descriptor
> *altsd,
> unsigned int attr) > {
> ....
> switch (subs->stream->chip->usb_id) {
> ....
> caseUSB_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) { > gotoadd_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
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
Quoted 186 lines · Takashi Iwai
Quoted 4 lines · 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,
Quoted 2 lines
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
Quoted 3 lines
the patch.
So I, personally, think it is beyond brand and is device range or
generation
Quoted 1 line
specific. I guess it is possible there may be some technical
parameter within
Quoted 1 line
the device descriptor which could indicate which variant the device is,
but I
Quoted 1 line
don't know what that might be (if at all). At this point I think we
probably
Quoted 3 lines
have to apply a conditional setting based on the Product ID.
Given that, is it best to continue hacking these into
pcm.c, or shouldwe be
Quoted 1 line
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
Quoted 5 lines
Cheers,
Keith
Quoted 8 lines
On Wed, 14 Oct 2020 at 14:47, Takashi Iwai <[email protected]> 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? Theyboth
Quoted 22 lines
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 <[email protected]> wrote: > > On Wed, 14 Oct 2020 14:17:35 +0200, > Mailing Lists wrote: > >Quoted 8 lines
> > 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. Ihave
Quoted 11 lines
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 devicesdo not
Quoted 5 lines
need > quirks > > */ > > > > There's probably others too, such as the GT-100 (I believethe
Quoted 5 lines
GT-001
> and
> > GT-100 have similar hardware).
> >
> > My question is, should this just be submitted as a patch to
pcm.cQuoted 7 lines
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 codeagain,
Quoted 4 lines
and
> I noticed that basically the function should return 0 without
setting
> anything else even if you don't have the explicit ID checksthere.
Quoted 4 lines
Quoted 4 lines
The function looks like:
static int set_sync_ep_implicit_fb_quirk(struct
snd_usb_substreamQuoted 2 lines
*subs,
> structusb_device*dev,
Quoted 10 lines
Quoted 1 line
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 */Quoted 8 lines
> 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/*Quoted 3 lines
Roland > */ && > search_roland_implicit_fb(dev,
altsd->bInterfaceNumber+Quoted 10 lines
1, > altsd->bAlternateSetting, > &alts, &ep) >= 0) { > goto add_sync_ep; > } > > /* No quirk */ > return 0; > > ... and the lengthy if-conditions after the switch/case isapplied
Quoted 2 lines
Quoted 2 lines
only for Roland devices, hence it shouldn't influence on BOSS devices. After that point, the immediate return with 0, which
is
Quoted 2 lines
the
> same as we do in switch/case. So the explicit check of BOSSdevices
Quoted 17 lines
Quoted 11 lines
there looks superfluous.
thanks,
Takashi
--
--
Keith A Milner--
--
Keith A Milner
Signature · 2 lines
-- Keith A Milner
Quoted 5 lines · 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.
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
Quoted 200 lines
Cheers,
Keith
On Wed, 14 Oct 2020 at 15:00, Takashi Iwai <[email protected]> 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 intopcm.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 <[email protected]> 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 <[email protected]> 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 inpcm.c
> set_sync_ep_implicit_fb_quirk:
> > >
> > > caseUSB_ID(0x0582, 0x01d8): /* BOSS Katana */ > > > caseUSB_ID(0x0582, 0x0130): /* BOSS Micro BR-80 */ > > > caseUSB_ID(0x0582, 0x0138): /* BOSS RC-300 */ > > > caseUSB_ID(0x0582, 0x01d6): /* BOSS GT-1 */ > > > caseUSB_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 topcm.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(structsnd_usb_substream
> *subs,
> > structusb_device*dev,
> > struct
> usb_interface_descriptor
> > *altsd,
> > unsigned int attr) > > {
> > ....
> > switch (subs->stream->chip->usb_id) {
> > ....
> > caseUSB_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) { > > gotoadd_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
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
Quoted 83 lines · 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.cset_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.cor 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
Quoted 34 lines · Takashi Iwai
Quoted 2 lines · Szabolcs Szőke
BOSS Katana amplifiers cannot be used for recording or playback if
quirks
Quoted 4 lines
are applied
Signed-off-by Szabolcs Szőke <[email protected]>Applied now. Thanks.
Takashi
sound/usb/pcm.c static int set_sync_ep_implicit_fb_quirk(struct
Quoted 10 lines
--- sound/usb/pcm.c | 3 +++ 1 file changed, 3 insertions(+)sound/usb/pcm.c +0
-0@@ -348,6 +348,9 @@ static int set_sync_ep_implicit_fb_quirk(struct
snd_usb_substream*subs,Quoted 8 lines
sound/usb/pcm.c +3
-0ep =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 ; }Quoted 9 lines
Quoted 4 lines
sound/usb/pcm.c +0
-1if (attr == USB_ENDPOINT_SYNC_ASYNC && --2.20.1
_______________________________________________
Alsa-devel mailing list
[email protected]
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel--
--
Keith A Milner
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
Quoted 102 lines · 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
Quoted 83 lines · 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.cset_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.cor 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
Quoted 34 lines · Takashi Iwai
Quoted 2 lines · Szabolcs Szőke
BOSS Katana amplifiers cannot be used for recording or playback if
quirks
Quoted 4 lines
are applied
Signed-off-by Szabolcs Szőke <[email protected]>Applied now. Thanks.
Takashi
sound/usb/pcm.c static int set_sync_ep_implicit_fb_quirk(struct
Quoted 10 lines
--- sound/usb/pcm.c | 3 +++ 1 file changed, 3 insertions(+)sound/usb/pcm.c +0
-0@@ -348,6 +348,9 @@ static int set_sync_ep_implicit_fb_quirk(struct
snd_usb_substream*subs,Quoted 8 lines
sound/usb/pcm.c +3
-0ep =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 ; }Quoted 9 lines
Quoted 4 lines
sound/usb/pcm.c +0
-1if (attr == USB_ENDPOINT_SYNC_ASYNC && --2.20.1
_______________________________________________
Alsa-devel mailing list
[email protected]
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel--
--
Keith A Milner
Signature · 2 lines
-- Keith A Milner
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
Quoted 118 lines · 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
Quoted 10 lines · 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
Quoted 92 lines
But maybe something else has changed in the handling of implicit feedback since then?
Mike
Quoted 83 lines · 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.cset_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.cor 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
Quoted 34 lines · Takashi Iwai
Quoted 2 lines · Szabolcs Szőke
BOSS Katana amplifiers cannot be used for recording or playback if
quirks
Quoted 4 lines
are applied
Signed-off-by Szabolcs Szőke <[email protected]>Applied now. Thanks.
Takashi
sound/usb/pcm.c static int set_sync_ep_implicit_fb_quirk(struct
Quoted 10 lines
--- sound/usb/pcm.c | 3 +++ 1 file changed, 3 insertions(+)sound/usb/pcm.c +0
-0@@ -348,6 +348,9 @@ static int set_sync_ep_implicit_fb_quirk(struct
snd_usb_substream*subs,Quoted 8 lines
sound/usb/pcm.c +3
-0ep =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 ; }Quoted 9 lines
Quoted 4 lines
sound/usb/pcm.c +0
-1if (attr == USB_ENDPOINT_SYNC_ASYNC && --2.20.1
_______________________________________________
Alsa-devel mailing list
[email protected]
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel--
--
Keith A Milner--
--
Keith A Milner
Quoted 3 lines · Mike Oliphant
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
Signature · 1 line
Keith A Milner
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
Quoted 191 lines · Mailing Lists
Quoted 3 lines · Mike Oliphant
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
idVendor0x0582Roland Corp.
idProduct0x01d6
bcdDevice 0.00iManufacturer 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 2bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 3
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress0x03EP 3 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize0x02001x 512 bytes
bInterval 4
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress0x85EP 5 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize0x02001x 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
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
Quoted 220 lines · 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 @720fb7cfNote the "Starting sync EP".
Mike
Quoted 192 lines · Mailing Lists
Quoted 3 lines · Mike Oliphant
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
idVendor0x0582Roland Corp.
idProduct0x01d6
bcdDevice 0.00iManufacturer 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 2bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 3
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress0x03EP 3 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize0x02001x 512 bytes
bInterval 4
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress0x85EP 5 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize0x02001x 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
Signature · 2 lines
-- Keith A Milner
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
Quoted 243 lines · 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 @00000000d0aa6911Cheers,
Keith
Quoted 21 lines · 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 @720fb7cfQuoted 200 lines
Note the "Starting sync EP".
Mike
Quoted 192 lines · Mailing Lists
Quoted 3 lines · Mike Oliphant
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
idVendor0x0582Roland Corp.
idProduct0x01d6
bcdDevice 0.00iManufacturer 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 2bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 3
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress0x03EP 3 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize0x02001x 512 bytes
bInterval 4
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress0x85EP 5 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize0x02001x 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
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
Quoted 274 lines · 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
Quoted 244 lines · 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 @00000000d0aa6911Cheers,
Keith
Quoted 21 lines · 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 @720fb7cfQuoted 200 lines
Note the "Starting sync EP".
Mike
Quoted 192 lines · Mailing Lists
Quoted 3 lines · Mike Oliphant
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
idVendor0x0582Roland Corp.
idProduct0x01d6
bcdDevice 0.00iManufacturer 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 2bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 3
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress0x03EP 3 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize0x02001x 512 bytes
bInterval 4
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress0x85EP 5 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize0x02001x 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
Signature · 2 lines
-- Keith A Milner
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
Quoted 312 lines · 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 useSo, 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
Quoted 21 lines · 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
Quoted 255 lines
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
Quoted 245 lines · 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 @00000000d0aa6911Cheers,
Keith
Quoted 21 lines · 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 @720fb7cfQuoted 200 lines
Note the "Starting sync EP".
Mike
Quoted 192 lines · Mailing Lists
Quoted 3 lines · Mike Oliphant
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
idVendor0x0582Roland Corp.
idProduct0x01d6
bcdDevice 0.00iManufacturer 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 2bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 3
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress0x03EP 3 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize0x02001x 512 bytes
bInterval 4
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress0x85EP 5 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize0x02001x 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
Quoted 8 lines · 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.
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
Quoted 319 lines
Mike
Quoted 312 lines · 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 useSo, 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
Quoted 21 lines · 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
Quoted 255 lines
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
Quoted 245 lines · 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 @00000000d0aa6911Cheers,
Keith
Quoted 21 lines · 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 @720fb7cfQuoted 200 lines
Note the "Starting sync EP".
Mike
Quoted 192 lines · Mailing Lists
Quoted 3 lines · Mike Oliphant
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
idVendor0x0582Roland Corp.
idProduct0x01d6
bcdDevice 0.00iManufacturer 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 2bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 3
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress0x03EP 3 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize0x02001x 512 bytes
bInterval 4
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress0x85EP 5 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize0x02001x 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
Thanks for the input, Takashi - and I completely understand the difficulty in resolving problems for specific hardware that you don't have available.
Mike
Quoted 376 lines · Takashi Iwai
Quoted 2 lines · Mike Oliphant
Yeah, I think the work-around I found is just that - a solution that
works
Quoted 1 line
in my particular situation, but does not resolve what seems to be a
deeper
Quoted 3 lines
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
Quoted 2 lines
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
Quoted 7 lines
Mike
Quoted 1 line · Keith Milner
I thought I would re-try the change you made. When I tried this last
year
Quoted 3 lines
Quoted 3 lines
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
Quoted 1 line
Quoted 1 line
issues for me. For a start, it only works in Jack. If I try to access
the
Quoted 4 lines
Quoted 4 lines
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 inuse
Quoted 1 line
Quoted 1 line
[ 184.089232] usb 1-4: Unable to change format on ep #8e: already inuse
Quoted 1 line
Quoted 1 line
[ 184.089401] usb 1-4: Unable to change format on ep #8e: already inuse
Quoted 1 line
Quoted 1 line
[ 184.089619] usb 1-4: Unable to change format on ep #8e: already inuse
Quoted 7 lines
Quoted 7 lines
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
Quoted 4 lines
Quoted 4 lines
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
Quoted 7 lines
Quoted 7 lines
clear this one isn't solved yet.
Cheers,
Keith
On Wed, 14 Oct 2020 at 19:17, Mike Oliphant <[email protected]>
Quoted 2 lines · wrote:
Quoted 2 lines
Quoted 2 lines
That's also what I see from dmesg when I use the quirk device ID
patch.
Quoted 1 line
Quoted 1 line
Quoted 1 line
I'm pretty sure it means that implicit feedback is not being enabled
for
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
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
Quoted 1 line
Quoted 1 line
Quoted 1 line
implicit feedback code not wait to send data until it has received
some. It
Quoted 1 line
Quoted 1 line
Quoted 1 line
works perfectly for me, but success has been mixed for others so I
didn't
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
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
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
It outlines my struggle with this issue - from trying the quirk ID
patch,
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
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 <
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 4 lines · wrote:
Hi Mike,
I'm getting this:[Oct14 18:21] snd_usb_audio:set_format: usb 1-4: setting usb
interface
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
1:1
[ +0.000003] snd_usb_audio:snd_usb_add_endpoint: usb 1-4: Re-usingEP d
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
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 dataEP
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
@00000000d0aa6911
Cheers,
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Keith
Quoted 3 lines · Mike Oliphant
Hi Keith,
The lsusb output just shows that the endpoint is there, but not
that it
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
is getting connected when the device is initialized. Can you check
dmesg
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
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, 12urbs),
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
ret=0
[ 26.787685] usb 1-1.1: match_endpoint_audioformats: (fmt@6bc43c84)
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
score 2
[ 26.787745] usb 1-1.1: Setting params for ep #8e (type 0, 12urbs),
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
ret=0
[ 26.787751] usb 1-1.1: Starting data EP @a14130b5 [ 26.788420] usb 1-1.1: Starting sync EP @720fb7cfNote the "Starting sync EP".
Mike
On Wed, Oct 14, 2020 at 9:35 AM Mailing Lists <
Quoted 208 lines
Quoted 207 lines
Quoted 197 lines
Quoted 197 lines
Quoted 196 lines
Quoted 193 lines · wrote:
On Wed, 14 Oct 2020 at 17:12, Mike Oliphant <[email protected]
Quoted 3 lines · 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
idVendor0x0582Roland Corp.
idProduct0x01d6
bcdDevice 0.00iManufacturer 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 2bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 3
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress0x03EP 3 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize0x02001x 512 bytes
bInterval 4
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress0x85EP 5 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize0x02001x 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 MilnerQuoted 5 lines
Quoted 4 lines
--
--
Keith A Milner--
--
Keith A Milner