Re: [alsa-devel] [PATCH] ALSA: usb-audio: Disable quirks for BOSS Katana amplifiers
On Fri, 11 Oct 2019 19:19:36 +0200, Szabolcs Szőke wrote:
BOSS Katana amplifiers cannot be used for recording or playback if quirks are applied
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=195223 Signed-off-by: Szabolcs Szőke szszoke.code@gmail.com
Applied now. Thanks.
Takashi
sound/usb/pcm.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c index 33cd26763c0e..daadb0c66eee 100644 --- a/sound/usb/pcm.c +++ b/sound/usb/pcm.c @@ -348,6 +348,9 @@ static int set_sync_ep_implicit_fb_quirk(struct snd_usb_substream *subs, ep = 0x84; ifnum = 0; goto add_sync_ep_from_ifnum;
case USB_ID(0x0582, 0x01d8): /* BOSS Katana */
/* BOSS Katana amplifiers do not need quirks */return 0;}
if (attr == USB_ENDPOINT_SYNC_ASYNC &&
-- 2.20.1
Thank you for your help!
Den tors 17 okt. 2019 10:19Takashi Iwai tiwai@suse.de skrev:
On Fri, 11 Oct 2019 19:19:36 +0200, Szabolcs Szőke wrote:
BOSS Katana amplifiers cannot be used for recording or playback if quirks are applied
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=195223 Signed-off-by: Szabolcs Szőke szszoke.code@gmail.com
Applied now. Thanks.
Takashi
sound/usb/pcm.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c index 33cd26763c0e..daadb0c66eee 100644 --- a/sound/usb/pcm.c +++ b/sound/usb/pcm.c @@ -348,6 +348,9 @@ static int set_sync_ep_implicit_fb_quirk(struct
snd_usb_substream *subs,
ep = 0x84; ifnum = 0; goto add_sync_ep_from_ifnum;
case USB_ID(0x0582, 0x01d8): /* BOSS Katana *//* BOSS Katana amplifiers do not need quirks */return 0; } if (attr == USB_ENDPOINT_SYNC_ASYNC &&-- 2.20.1
Following up on this, it appears there are a bunch of the newer-generation Roland/Boss devices which need similar treatment.
So far I have tested the GT-1, the GT-001, and the BR-80, and others have reported the RC-300 as working with similar modifications. I have been using the following change to the code in pcm.c set_sync_ep_implicit_fb_quirk:
case USB_ID(0x0582, 0x01d8): /* BOSS Katana */ case USB_ID(0x0582, 0x0130): /* BOSS Micro BR-80 */ case USB_ID(0x0582, 0x0138): /* BOSS RC-300 */ case USB_ID(0x0582, 0x01d6): /* BOSS GT-1 */ case USB_ID(0x0582, 0x01e5): /* BOSS GT-001 */ /* BOSS Katana amplifiers and many other newer BOSS devices do not need quirks */
There's probably others too, such as the GT-100 (I believe the GT-001 and GT-100 have similar hardware).
My question is, should this just be submitted as a patch to pcm.c or would it be better handled in quirks and, if so, how?
Or something else?
Personally, I dislike the approach of hard-coding exceptions into core code as it seems that's what quirks are there for, but there seems to be a whole bunch of exceptions in there already.
Cheers,
Keith
On Thu, 17 Oct 2019 at 09:20, Takashi Iwai tiwai@suse.de wrote:
On Fri, 11 Oct 2019 19:19:36 +0200, Szabolcs Szőke wrote:
BOSS Katana amplifiers cannot be used for recording or playback if quirks are applied
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=195223 Signed-off-by: Szabolcs Szőke szszoke.code@gmail.com
Applied now. Thanks.
Takashi
sound/usb/pcm.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c index 33cd26763c0e..daadb0c66eee 100644 --- a/sound/usb/pcm.c +++ b/sound/usb/pcm.c @@ -348,6 +348,9 @@ static int set_sync_ep_implicit_fb_quirk(struct
snd_usb_substream *subs,
ep = 0x84; ifnum = 0; goto add_sync_ep_from_ifnum;
case USB_ID(0x0582, 0x01d8): /* BOSS Katana *//* BOSS Katana amplifiers do not need quirks */return 0; } if (attr == USB_ENDPOINT_SYNC_ASYNC &&-- 2.20.1
Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
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
Thanks for the response Takashi,
How should this be distinguishing between Roland and BOSS? They both have the vendor ID 0x0582.
Cheers,
Keith
On Wed, 14 Oct 2020 at 14:09, Takashi Iwai tiwai@suse.de wrote:
On Wed, 14 Oct 2020 14:17:35 +0200, Mailing Lists wrote:
Following up on this, it appears there are a bunch of the
newer-generation
Roland/Boss devices which need similar treatment.
So far I have tested the GT-1, the GT-001, and the BR-80, and others have reported the RC-300 as working with similar modifications. I have been
using
the following change to the code in pcm.c set_sync_ep_implicit_fb_quirk:
case USB_ID(0x0582, 0x01d8): /* BOSS Katana */ case USB_ID(0x0582, 0x0130): /* BOSS Micro BR-80 */ case USB_ID(0x0582, 0x0138): /* BOSS RC-300 */ case USB_ID(0x0582, 0x01d6): /* BOSS GT-1 */ case USB_ID(0x0582, 0x01e5): /* BOSS GT-001 *//* BOSS Katana amplifiers and many other newer BOSS devices do not need
quirks
*/
There's probably others too, such as the GT-100 (I believe the GT-001 and GT-100 have similar hardware).
My question is, should this just be submitted as a patch to pcm.c or
would it
be better handled in quirks and, if so, how?
Or something else?
Do we really need this change at all? I looked at the code again, and I noticed that basically the function should return 0 without setting anything else even if you don't have the explicit ID checks there.
The function looks like:
static int set_sync_ep_implicit_fb_quirk(struct snd_usb_substream *subs, struct usb_device *dev, struct usb_interface_descriptor *altsd, unsigned int attr) { .... switch (subs->stream->chip->usb_id) { .... case USB_ID(0x0582, 0x01d8): /* BOSS Katana */ /* BOSS Katana amplifiers do not need quirks */ return 0; }
if (attr == USB_ENDPOINT_SYNC_ASYNC && altsd->bInterfaceClass == USB_CLASS_VENDOR_SPEC && altsd->bInterfaceProtocol == 2 && altsd->bNumEndpoints == 1 && USB_ID_VENDOR(subs->stream->chip->usb_id) == 0x0582 /* Roland*/ && search_roland_implicit_fb(dev, altsd->bInterfaceNumber + 1, altsd->bAlternateSetting, &alts, &ep) >= 0) { goto add_sync_ep; }
/* No quirk */ return 0;... and the lengthy if-conditions after the switch/case is applied only for Roland devices, hence it shouldn't influence on BOSS devices. After that point, the immediate return with 0, which is the same as we do in switch/case. So the explicit check of BOSS devices there looks superfluous.
thanks,
Takashi
On Wed, 14 Oct 2020 15:33:03 +0200, Mailing Lists wrote:
Thanks for the response Takashi,
How should this be distinguishing between Roland and BOSS? They both have the vendor ID 0x0582.
Ah, right, I missed that point :-<
So the question would be rather how to detect BOSS devices effectively...
thanks,
Takashi
Cheers,
Keith
On Wed, 14 Oct 2020 at 14:09, Takashi Iwai tiwai@suse.de wrote:
On Wed, 14 Oct 2020 14:17:35 +0200, Mailing Lists wrote: > > Following up on this, it appears there are a bunch of the newer-generation > Roland/Boss devices which need similar treatment. > > So far I have tested the GT-1, the GT-001, and the BR-80, and others have > reported the RC-300 as working with similar modifications. I have been using > the following change to the code in pcm.c set_sync_ep_implicit_fb_quirk: > > case USB_ID(0x0582, 0x01d8): /* BOSS Katana */ > case USB_ID(0x0582, 0x0130): /* BOSS Micro BR-80 */ > case USB_ID(0x0582, 0x0138): /* BOSS RC-300 */ > case USB_ID(0x0582, 0x01d6): /* BOSS GT-1 */ > case USB_ID(0x0582, 0x01e5): /* BOSS GT-001 */ > /* BOSS Katana amplifiers and many other newer BOSS devices do not need quirks > */ > > There's probably others too, such as the GT-100 (I believe the GT-001 and > GT-100 have similar hardware). > > My question is, should this just be submitted as a patch to pcm.c or would it > be better handled in quirks and, if so, how? > > Or something else? Do we really need this change at all? I looked at the code again, and I noticed that basically the function should return 0 without setting anything else even if you don't have the explicit ID checks there. The function looks like: static int set_sync_ep_implicit_fb_quirk(struct snd_usb_substream *subs, struct usb_device *dev, struct usb_interface_descriptor *altsd, unsigned int attr) { .... switch (subs->stream->chip->usb_id) { .... case USB_ID(0x0582, 0x01d8): /* BOSS Katana */ /* BOSS Katana amplifiers do not need quirks */ return 0; } if (attr == USB_ENDPOINT_SYNC_ASYNC && altsd->bInterfaceClass == USB_CLASS_VENDOR_SPEC && altsd->bInterfaceProtocol == 2 && altsd->bNumEndpoints == 1 && USB_ID_VENDOR(subs->stream->chip->usb_id) == 0x0582 /* Roland */ && search_roland_implicit_fb(dev, altsd->bInterfaceNumber + 1, altsd->bAlternateSetting, &alts, &ep) >= 0) { goto add_sync_ep; } /* No quirk */ return 0; ... and the lengthy if-conditions after the switch/case is applied only for Roland devices, hence it shouldn't influence on BOSS devices. After that point, the immediate return with 0, which is the same as we do in switch/case. So the explicit check of BOSS devices there looks superfluous. thanks, Takashi--
Keith A Milner
Yes, and I don't think this is practical (at least, not obviously).
The "Roland" vs "BOSS" thing is pure branding. I have BOSS branded devices, like the JS-8, which work perfectly without the patch as an example. It wouldn't surprise me if there are recent Roland branded devices which require the patch.
So I, personally, think it is beyond brand and is device range or generation specific. I guess it is possible there may be some technical parameter within the device descriptor which could indicate which variant the device is, but I don't know what that might be (if at all). At this point I think we probably have to apply a conditional setting based on the Product ID.
Given that, is it best to continue hacking these into pcm.c, or should we be looking at a quirks-table way to describe these?
Cheers,
Keith
On Wed, 14 Oct 2020 at 14:47, Takashi Iwai tiwai@suse.de wrote:
On Wed, 14 Oct 2020 15:33:03 +0200, Mailing Lists wrote:
Thanks for the response Takashi,
How should this be distinguishing between Roland and BOSS? They both
have the
vendor ID 0x0582.
Ah, right, I missed that point :-<
So the question would be rather how to detect BOSS devices effectively...
thanks,
Takashi
Cheers,
Keith
On Wed, 14 Oct 2020 at 14:09, Takashi Iwai tiwai@suse.de wrote:
On Wed, 14 Oct 2020 14:17:35 +0200, Mailing Lists wrote: > > Following up on this, it appears there are a bunch of the newer-generation > Roland/Boss devices which need similar treatment. > > So far I have tested the GT-1, the GT-001, and the BR-80, andothers
have > reported the RC-300 as working with similar modifications. I havebeen
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 notneed
quirks > */ > > There's probably others too, such as the GT-100 (I believe theGT-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, 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--
Keith A Milner
On Wed, 14 Oct 2020 15:56:32 +0200, Mailing Lists wrote:
Yes, and I don't think this is practical (at least, not obviously).
The "Roland" vs "BOSS" thing is pure branding. I have BOSS branded devices, like the JS-8, which work perfectly without the patch as an example. It wouldn't surprise me if there are recent Roland branded devices which require the patch.
So I, personally, think it is beyond brand and is device range or generation specific. I guess it is possible there may be some technical parameter within the device descriptor which could indicate which variant the device is, but I don't know what that might be (if at all). At this point I think we probably have to apply a conditional setting based on the Product ID.
Given that, is it best to continue hacking these into pcm.c, or should we be looking at a quirks-table way to describe these?
Currently it's better to grow the explicit allow-list, I suppose. Those are still handful, hence manageable enough.
But, we should consider improving search_roland_implicit_fb(), too. Both actions don't conflict, and once after we establish the better implicit-fb check, the allow-list can be dropped.
thanks,
Takashi
Cheers,
Keith
On Wed, 14 Oct 2020 at 14:47, Takashi Iwai tiwai@suse.de wrote:
On Wed, 14 Oct 2020 15:33:03 +0200, Mailing Lists wrote: > > Thanks for the response Takashi, > > How should this be distinguishing between Roland and BOSS? They both have the > vendor ID 0x0582. Ah, right, I missed that point :-< So the question would be rather how to detect BOSS devices effectively... thanks, Takashi > > Cheers, > > Keith > > On Wed, 14 Oct 2020 at 14:09, Takashi Iwai <tiwai@suse.de> wrote: > > On Wed, 14 Oct 2020 14:17:35 +0200, > Mailing Lists wrote: > > > > Following up on this, it appears there are a bunch of the > newer-generation > > Roland/Boss devices which need similar treatment. > > > > So far I have tested the GT-1, the GT-001, and the BR-80, and others > have > > reported the RC-300 as working with similar modifications. I have been > using > > the following change to the code in pcm.c set_sync_ep_implicit_fb_quirk: > > > > case USB_ID(0x0582, 0x01d8): /* BOSS Katana */ > > case USB_ID(0x0582, 0x0130): /* BOSS Micro BR-80 */ > > case USB_ID(0x0582, 0x0138): /* BOSS RC-300 */ > > case USB_ID(0x0582, 0x01d6): /* BOSS GT-1 */ > > case USB_ID(0x0582, 0x01e5): /* BOSS GT-001 */ > > /* BOSS Katana amplifiers and many other newer BOSS devices do not need > quirks > > */ > > > > There's probably others too, such as the GT-100 (I believe the GT-001 > and > > GT-100 have similar hardware). > > > > My question is, should this just be submitted as a patch to pcm.c or > would it > > be better handled in quirks and, if so, how? > > > > Or something else? > > Do we really need this change at all? I looked at the code again, and > I noticed that basically the function should return 0 without setting > anything else even if you don't have the explicit ID checks there. > > The function looks like: > > static int set_sync_ep_implicit_fb_quirk(struct snd_usb_substream *subs, > struct usb_device *dev, > struct usb_interface_descriptor > *altsd, > unsigned int attr) > { > .... > switch (subs->stream->chip->usb_id) { > .... > case USB_ID(0x0582, 0x01d8): /* BOSS Katana */ > /* BOSS Katana amplifiers do not need quirks */ > return 0; > } > > if (attr == USB_ENDPOINT_SYNC_ASYNC && > altsd->bInterfaceClass == USB_CLASS_VENDOR_SPEC && > altsd->bInterfaceProtocol == 2 && > altsd->bNumEndpoints == 1 && > USB_ID_VENDOR(subs->stream->chip->usb_id) == 0x0582 /* Roland > */ && > search_roland_implicit_fb(dev, altsd->bInterfaceNumber + 1, > altsd->bAlternateSetting, > &alts, &ep) >= 0) { > goto add_sync_ep; > } > > /* No quirk */ > return 0; > > ... and the lengthy if-conditions after the switch/case is applied > only for Roland devices, hence it shouldn't influence on BOSS > devices. After that point, the immediate return with 0, which is the > same as we do in switch/case. So the explicit check of BOSS devices > there looks superfluous. > > thanks, > > Takashi > > -- > -- > Keith A Milner > >--
Keith A Milner
OK, I will do that.
Quick question: what is the best git I should clone to create patches against these days? I've been out of the loop for a few years now.
Cheers,
Keith
On Wed, 14 Oct 2020 at 15:00, Takashi Iwai tiwai@suse.de wrote:
On Wed, 14 Oct 2020 15:56:32 +0200, Mailing Lists wrote:
Yes, and I don't think this is practical (at least, not obviously).
The "Roland" vs "BOSS" thing is pure branding. I have BOSS branded
devices,
like the JS-8, which work perfectly without the patch as an example. It wouldn't surprise me if there are recent Roland branded devices which
require
the patch.
So I, personally, think it is beyond brand and is device range or
generation
specific. I guess it is possible there may be some technical
parameter within
the device descriptor which could indicate which variant the device is,
but I
don't know what that might be (if at all). At this point I think we
probably
have to apply a conditional setting based on the Product ID.
Given that, is it best to continue hacking these into pcm.c, or should
we be
looking at a quirks-table way to describe these?
Currently it's better to grow the explicit allow-list, I suppose. Those are still handful, hence manageable enough.
But, we should consider improving search_roland_implicit_fb(), too. Both actions don't conflict, and once after we establish the better implicit-fb check, the allow-list can be dropped.
thanks,
Takashi
Cheers,
Keith
On Wed, 14 Oct 2020 at 14:47, Takashi Iwai tiwai@suse.de wrote:
On Wed, 14 Oct 2020 15:33:03 +0200, Mailing Lists wrote: > > Thanks for the response Takashi, > > How should this be distinguishing between Roland and BOSS? Theyboth
have the > vendor ID 0x0582. Ah, right, I missed that point :-< So the question would be rather how to detect BOSS devices effectively... thanks, Takashi > > Cheers, > > Keith > > On Wed, 14 Oct 2020 at 14:09, Takashi Iwai <tiwai@suse.de> wrote: > > On Wed, 14 Oct 2020 14:17:35 +0200, > Mailing Lists wrote: > > > > Following up on this, it appears there are a bunch of the > newer-generation > > Roland/Boss devices which need similar treatment. > > > > So far I have tested the GT-1, the GT-001, and the BR-80, and others > have > > reported the RC-300 as working with similar modifications. Ihave
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
need > quirks > > */ > > > > There's probably others too, such as the GT-100 (I believethe
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 codeagain,
and > I noticed that basically the function should return 0 without setting > anything else even if you don't have the explicit ID checksthere.
> > The function looks like: > > static int set_sync_ep_implicit_fb_quirk(structsnd_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 isapplied
> only for Roland devices, hence it shouldn't influence on BOSS > devices. After that point, the immediate return with 0, whichis
the > same as we do in switch/case. So the explicit check of BOSSdevices
> there looks superfluous. > > thanks, > > Takashi > > -- > -- > Keith A Milner > >--
Keith A Milner
On Wed, 14 Oct 2020 16:31:02 +0200, Mailing Lists wrote:
OK, I will do that.
Quick question: what is the best git I should clone to create patches against these days? I've been out of the loop for a few years now.
At best, for-linus branch of my sound.git tree git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
There is a copy in github, too.
Takashi
Cheers,
Keith
On Wed, 14 Oct 2020 at 15:00, Takashi Iwai tiwai@suse.de wrote:
On Wed, 14 Oct 2020 15:56:32 +0200, Mailing Lists wrote: > > Yes, and I don't think this is practical (at least, not obviously). > > The "Roland" vs "BOSS" thing is pure branding. I have BOSS branded devices, > like the JS-8, which work perfectly without the patch as an example. It > wouldn't surprise me if there are recent Roland branded devices which require > the patch. > > So I, personally, think it is beyond brand and is device range or generation > specific. I guess it is possible there may be some technical parameter within > the device descriptor which could indicate which variant the device is, but I > don't know what that might be (if at all). At this point I think we probably > have to apply a conditional setting based on the Product ID. > > Given that, is it best to continue hacking these into pcm.c, or should we be > looking at a quirks-table way to describe these? Currently it's better to grow the explicit allow-list, I suppose. Those are still handful, hence manageable enough. But, we should consider improving search_roland_implicit_fb(), too. Both actions don't conflict, and once after we establish the better implicit-fb check, the allow-list can be dropped. thanks, Takashi > > Cheers, > > Keith > > On Wed, 14 Oct 2020 at 14:47, Takashi Iwai <tiwai@suse.de> wrote: > > On Wed, 14 Oct 2020 15:33:03 +0200, > Mailing Lists wrote: > > > > Thanks for the response Takashi, > > > > How should this be distinguishing between Roland and BOSS? They both > have the > > vendor ID 0x0582. > > Ah, right, I missed that point :-< > > So the question would be rather how to detect BOSS devices > effectively... > > thanks, > > Takashi > > > > > Cheers, > > > > Keith > > > > On Wed, 14 Oct 2020 at 14:09, Takashi Iwai <tiwai@suse.de> wrote: > > > > On Wed, 14 Oct 2020 14:17:35 +0200, > > Mailing Lists wrote: > > > > > > Following up on this, it appears there are a bunch of the > > newer-generation > > > Roland/Boss devices which need similar treatment. > > > > > > So far I have tested the GT-1, the GT-001, and the BR-80, and > others > > have > > > reported the RC-300 as working with similar modifications. I have > been > > using > > > the following change to the code in pcm.c > set_sync_ep_implicit_fb_quirk: > > > > > > case USB_ID(0x0582, 0x01d8): /* BOSS Katana */ > > > case USB_ID(0x0582, 0x0130): /* BOSS Micro BR-80 */ > > > case USB_ID(0x0582, 0x0138): /* BOSS RC-300 */ > > > case USB_ID(0x0582, 0x01d6): /* BOSS GT-1 */ > > > case USB_ID(0x0582, 0x01e5): /* BOSS GT-001 */ > > > /* BOSS Katana amplifiers and many other newer BOSS devices do not > need > > quirks > > > */ > > > > > > There's probably others too, such as the GT-100 (I believe the > GT-001 > > and > > > GT-100 have similar hardware). > > > > > > My question is, should this just be submitted as a patch to pcm.c > or > > would it > > > be better handled in quirks and, if so, how? > > > > > > Or something else? > > > > Do we really need this change at all? I looked at the code again, > and > > I noticed that basically the function should return 0 without > setting > > anything else even if you don't have the explicit ID checks there. > > > > The function looks like: > > > > static int set_sync_ep_implicit_fb_quirk(struct snd_usb_substream > *subs, > > struct usb_device *dev, > > struct > usb_interface_descriptor > > *altsd, > > unsigned int attr) > > { > > .... > > switch (subs->stream->chip->usb_id) { > > .... > > case USB_ID(0x0582, 0x01d8): /* BOSS Katana */ > > /* BOSS Katana amplifiers do not need quirks * / > > return 0; > > } > > > > if (attr == USB_ENDPOINT_SYNC_ASYNC && > > altsd->bInterfaceClass == USB_CLASS_VENDOR_SPEC && > > altsd->bInterfaceProtocol == 2 && > > altsd->bNumEndpoints == 1 && > > USB_ID_VENDOR(subs->stream->chip->usb_id) == 0x0582 /* > Roland > > */ && > > search_roland_implicit_fb(dev, altsd-> bInterfaceNumber + > 1, > > altsd-> bAlternateSetting, > > &alts, &ep) >= 0) { > > goto add_sync_ep; > > } > > > > /* No quirk */ > > return 0; > > > > ... and the lengthy if-conditions after the switch/case is applied > > only for Roland devices, hence it shouldn't influence on BOSS > > devices. After that point, the immediate return with 0, which is > the > > same as we do in switch/case. So the explicit check of BOSS devices > > there looks superfluous. > > > > thanks, > > > > Takashi > > > > -- > > -- > > Keith A Milner > > > > > > -- > -- > Keith A Milner > >--
Keith A Milner
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.ht...
But maybe something else has changed in the handling of implicit feedback since then?
Mike
On Wed, Oct 14, 2020 at 5:17 AM Mailing Lists maillist@superlative.org wrote:
Following up on this, it appears there are a bunch of the newer-generation Roland/Boss devices which need similar treatment.
So far I have tested the GT-1, the GT-001, and the BR-80, and others have reported the RC-300 as working with similar modifications. I have been using the following change to the code in pcm.c set_sync_ep_implicit_fb_quirk:
case USB_ID(0x0582, 0x01d8): /* BOSS Katana */ case USB_ID(0x0582, 0x0130): /* BOSS Micro BR-80 */ case USB_ID(0x0582, 0x0138): /* BOSS RC-300 */ case USB_ID(0x0582, 0x01d6): /* BOSS GT-1 */ case USB_ID(0x0582, 0x01e5): /* BOSS GT-001 *//* BOSS Katana amplifiers and many other newer BOSS devices do not need quirks */
There's probably others too, such as the GT-100 (I believe the GT-001 and GT-100 have similar hardware).
My question is, should this just be submitted as a patch to pcm.c or would it be better handled in quirks and, if so, how?
Or something else?
Personally, I dislike the approach of hard-coding exceptions into core code as it seems that's what quirks are there for, but there seems to be a whole bunch of exceptions in there already.
Cheers,
Keith
On Thu, 17 Oct 2019 at 09:20, Takashi Iwai tiwai@suse.de wrote:
On Fri, 11 Oct 2019 19:19:36 +0200, Szabolcs Szőke wrote:
BOSS Katana amplifiers cannot be used for recording or playback if
quirks
are applied
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=195223 Signed-off-by: Szabolcs Szőke szszoke.code@gmail.com
Applied now. Thanks.
Takashi
sound/usb/pcm.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c index 33cd26763c0e..daadb0c66eee 100644 --- a/sound/usb/pcm.c +++ b/sound/usb/pcm.c @@ -348,6 +348,9 @@ static int set_sync_ep_implicit_fb_quirk(struct
snd_usb_substream *subs,
ep = 0x84; ifnum = 0; goto add_sync_ep_from_ifnum;
case USB_ID(0x0582, 0x01d8): /* BOSS Katana *//* BOSS Katana amplifiers do not need quirks */return 0; } if (attr == USB_ENDPOINT_SYNC_ASYNC &&-- 2.20.1
Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
--
Keith A Milner
Hi Mike, That's odd. I've been using the patches in this thread with both my GT-001 and my GT-1 with no issues for a few weeks now. Of course that might be pure dumb luck and differences in hardware, interrupts, and so on.
Cheers,
Keith
On Wed, 14 Oct 2020 at 16:19, Mike Oliphant oliphant@nostatic.org wrote:
When I tried this change earlier this year on the BOSS GT-1, it enabled sound output on the card (which was not previously working), but with significant issues. It resulted in frequent pops and crackles - presumably because of the loss of synchronization using implicit feedback.
This was the fix that ended up working for me:
https://mailman.alsa-project.org/pipermail/alsa-devel/2020-January/161951.ht...
But maybe something else has changed in the handling of implicit feedback since then?
Mike
On Wed, Oct 14, 2020 at 5:17 AM Mailing Lists maillist@superlative.org wrote:
Following up on this, it appears there are a bunch of the newer-generation Roland/Boss devices which need similar treatment.
So far I have tested the GT-1, the GT-001, and the BR-80, and others have reported the RC-300 as working with similar modifications. I have been using the following change to the code in pcm.c set_sync_ep_implicit_fb_quirk:
case USB_ID(0x0582, 0x01d8): /* BOSS Katana */ case USB_ID(0x0582, 0x0130): /* BOSS Micro BR-80 */ case USB_ID(0x0582, 0x0138): /* BOSS RC-300 */ case USB_ID(0x0582, 0x01d6): /* BOSS GT-1 */ case USB_ID(0x0582, 0x01e5): /* BOSS GT-001 *//* BOSS Katana amplifiers and many other newer BOSS devices do not need quirks */
There's probably others too, such as the GT-100 (I believe the GT-001 and GT-100 have similar hardware).
My question is, should this just be submitted as a patch to pcm.c or would it be better handled in quirks and, if so, how?
Or something else?
Personally, I dislike the approach of hard-coding exceptions into core code as it seems that's what quirks are there for, but there seems to be a whole bunch of exceptions in there already.
Cheers,
Keith
On Thu, 17 Oct 2019 at 09:20, Takashi Iwai tiwai@suse.de wrote:
On Fri, 11 Oct 2019 19:19:36 +0200, Szabolcs Szőke wrote:
BOSS Katana amplifiers cannot be used for recording or playback if
quirks
are applied
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=195223 Signed-off-by: Szabolcs Szőke szszoke.code@gmail.com
Applied now. Thanks.
Takashi
sound/usb/pcm.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c index 33cd26763c0e..daadb0c66eee 100644 --- a/sound/usb/pcm.c +++ b/sound/usb/pcm.c @@ -348,6 +348,9 @@ static int set_sync_ep_implicit_fb_quirk(struct
snd_usb_substream *subs,
ep = 0x84; ifnum = 0; goto add_sync_ep_from_ifnum;
case USB_ID(0x0582, 0x01d8): /* BOSS Katana *//* BOSS Katana amplifiers do not need quirks */return 0; } if (attr == USB_ENDPOINT_SYNC_ASYNC &&-- 2.20.1
Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
--
Keith A Milner
Keith - are you getting an implicit feedback endpoint created when you run with the patch?
When I patched the GT-1 device ID into the quirk code, I ended up with no implicit feedback endpoint created. Without running in implicit feedback mode, I assume that you are relying on how well the clocks match. In my case, my card's clock was a bit fast. If I hardcoded the sample rate in 'sound/usb/format.c' to 44105, my pops and crackles mostly went away - more like every few minutes instead of every few seconds.
Maybe your card just has a clock closer to 44100? Or, as I said in my last message, maybe something else has changed in the kernel since earlier this year?
Mike
On Wed, Oct 14, 2020 at 8:35 AM Mailing Lists maillist@superlative.org wrote:
Hi Mike, That's odd. I've been using the patches in this thread with both my GT-001 and my GT-1 with no issues for a few weeks now. Of course that might be pure dumb luck and differences in hardware, interrupts, and so on.
Cheers,
Keith
On Wed, 14 Oct 2020 at 16:19, Mike Oliphant oliphant@nostatic.org wrote:
When I tried this change earlier this year on the BOSS GT-1, it enabled sound output on the card (which was not previously working), but with significant issues. It resulted in frequent pops and crackles - presumably because of the loss of synchronization using implicit feedback.
This was the fix that ended up working for me:
https://mailman.alsa-project.org/pipermail/alsa-devel/2020-January/161951.ht...
But maybe something else has changed in the handling of implicit feedback since then?
Mike
On Wed, Oct 14, 2020 at 5:17 AM Mailing Lists maillist@superlative.org wrote:
Following up on this, it appears there are a bunch of the newer-generation Roland/Boss devices which need similar treatment.
So far I have tested the GT-1, the GT-001, and the BR-80, and others have reported the RC-300 as working with similar modifications. I have been using the following change to the code in pcm.c set_sync_ep_implicit_fb_quirk:
case USB_ID(0x0582, 0x01d8): /* BOSS Katana */ case USB_ID(0x0582, 0x0130): /* BOSS Micro BR-80 */ case USB_ID(0x0582, 0x0138): /* BOSS RC-300 */ case USB_ID(0x0582, 0x01d6): /* BOSS GT-1 */ case USB_ID(0x0582, 0x01e5): /* BOSS GT-001 *//* BOSS Katana amplifiers and many other newer BOSS devices do not need quirks */
There's probably others too, such as the GT-100 (I believe the GT-001 and GT-100 have similar hardware).
My question is, should this just be submitted as a patch to pcm.c or would it be better handled in quirks and, if so, how?
Or something else?
Personally, I dislike the approach of hard-coding exceptions into core code as it seems that's what quirks are there for, but there seems to be a whole bunch of exceptions in there already.
Cheers,
Keith
On Thu, 17 Oct 2019 at 09:20, Takashi Iwai tiwai@suse.de wrote:
On Fri, 11 Oct 2019 19:19:36 +0200, Szabolcs Szőke wrote:
BOSS Katana amplifiers cannot be used for recording or playback if
quirks
are applied
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=195223 Signed-off-by: Szabolcs Szőke szszoke.code@gmail.com
Applied now. Thanks.
Takashi
sound/usb/pcm.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c index 33cd26763c0e..daadb0c66eee 100644 --- a/sound/usb/pcm.c +++ b/sound/usb/pcm.c @@ -348,6 +348,9 @@ static int set_sync_ep_implicit_fb_quirk(struct
snd_usb_substream *subs,
ep = 0x84; ifnum = 0; goto add_sync_ep_from_ifnum;
case USB_ID(0x0582, 0x01d8): /* BOSS Katana *//* BOSS Katana amplifiers do not need quirks */return 0; } if (attr == USB_ENDPOINT_SYNC_ASYNC &&-- 2.20.1
Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
--
Keith A Milner
--
Keith A Milner
On Wed, 14 Oct 2020 at 17:12, Mike Oliphant oliphant@nostatic.org wrote:
Keith - are you getting an implicit feedback endpoint created when you run with the patch?
Hi Mike,
It appears that I do. For reference I'm on kernel 5.4.0-51:
Bus 001 Device 007: ID 0582:01d6 Roland Corp. GT-1 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 255 bMaxPacketSize0 64 idVendor 0x0582 Roland Corp. idProduct 0x01d6 bcdDevice 0.00 iManufacturer 1 BOSS iProduct 2 GT-1 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x00bc bNumInterfaces 4 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 2 iInterface 0 ** UNRECOGNIZED: 06 24 f1 01 00 00 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 2 iInterface 0 ** UNRECOGNIZED: 07 24 01 01 00 01 00 ** UNRECOGNIZED: 0b 24 02 01 02 04 18 01 44 ac 00 ** UNRECOGNIZED: 06 24 f1 04 16 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x0d EP 13 OUT bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x0038 1x 56 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 1 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 1 iInterface 0 ** UNRECOGNIZED: 07 24 01 07 00 01 00 ** UNRECOGNIZED: 0b 24 02 01 02 04 18 01 44 ac 00 ** UNRECOGNIZED: 06 24 f1 04 16 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x8e EP 14 IN bmAttributes 37 Transfer Type Isochronous Synch Type Asynchronous Usage Type Implicit feedback Data wMaxPacketSize 0x0038 1x 56 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 3 bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 06 24 f1 02 01 01 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 3 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 4 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 4 Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 255 bMaxPacketSize0 64 bNumConfigurations 1 can't get debug descriptor: Resource temporarily unavailable Device Status: 0x0001 Self Powered
Hi Keith,
The lsusb output just shows that the endpoint is there, but not that it is getting connected when the device is initialized. Can you check dmesg output when you use the device for playback?
This is what I see from dmesg when the implicit feedback endpoint is being used:
[ 26.787360] usb 1-1.1: setting usb interface 1:1 [ 26.787367] Creating new playback data endpoint #d [ 26.787375] Creating new capture data endpoint #8e [ 26.787678] usb 1-1.1: Setting params for ep #d (type 0, 12 urbs), ret=0 [ 26.787685] usb 1-1.1: match_endpoint_audioformats: (fmt @6bc43c84) score 2 [ 26.787745] usb 1-1.1: Setting params for ep #8e (type 0, 12 urbs), ret=0 [ 26.787751] usb 1-1.1: Starting data EP @a14130b5 [ 26.788420] usb 1-1.1: Starting sync EP @720fb7cf
Note the "Starting sync EP".
Mike
On Wed, Oct 14, 2020 at 9:35 AM Mailing Lists maillist@superlative.org wrote:
On Wed, 14 Oct 2020 at 17:12, Mike Oliphant oliphant@nostatic.org wrote:
Keith - are you getting an implicit feedback endpoint created when you run with the patch?
Hi Mike,
It appears that I do. For reference I'm on kernel 5.4.0-51:
Bus 001 Device 007: ID 0582:01d6 Roland Corp. GT-1 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 255 bMaxPacketSize0 64 idVendor 0x0582 Roland Corp. idProduct 0x01d6 bcdDevice 0.00 iManufacturer 1 BOSS iProduct 2 GT-1 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x00bc bNumInterfaces 4 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 2 iInterface 0 ** UNRECOGNIZED: 06 24 f1 01 00 00 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 2 iInterface 0 ** UNRECOGNIZED: 07 24 01 01 00 01 00 ** UNRECOGNIZED: 0b 24 02 01 02 04 18 01 44 ac 00 ** UNRECOGNIZED: 06 24 f1 04 16 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x0d EP 13 OUT bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x0038 1x 56 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 1 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 1 iInterface 0 ** UNRECOGNIZED: 07 24 01 07 00 01 00 ** UNRECOGNIZED: 0b 24 02 01 02 04 18 01 44 ac 00 ** UNRECOGNIZED: 06 24 f1 04 16 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x8e EP 14 IN bmAttributes 37 Transfer Type Isochronous Synch Type Asynchronous Usage Type Implicit feedback Data wMaxPacketSize 0x0038 1x 56 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 3 bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 06 24 f1 02 01 01 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 3 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 4 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 4 Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 255 bMaxPacketSize0 64 bNumConfigurations 1 can't get debug descriptor: Resource temporarily unavailable Device Status: 0x0001 Self Powered
-- Keith A Milner
Hi Mike, I'm getting this:
[Oct14 18:21] snd_usb_audio:set_format: usb 1-4: setting usb interface 1:1 [ +0.000003] snd_usb_audio:snd_usb_add_endpoint: usb 1-4: Re-using EP d in iface 1,1 @00000000d0aa6911 [ +0.000018] snd_usb_audio:snd_usb_endpoint_set_params: usb 1-4: Setting params for ep #d (type 0, 3 urbs), ret=0 [ +0.000002] snd_usb_audio:start_endpoints: usb 1-4: Starting data EP @00000000d0aa6911
Cheers,
Keith
On Wed, 14 Oct 2020 at 17:46, Mike Oliphant oliphant@nostatic.org wrote:
Hi Keith,
The lsusb output just shows that the endpoint is there, but not that it is getting connected when the device is initialized. Can you check dmesg output when you use the device for playback?
This is what I see from dmesg when the implicit feedback endpoint is being used:
[ 26.787360] usb 1-1.1: setting usb interface 1:1 [ 26.787367] Creating new playback data endpoint #d [ 26.787375] Creating new capture data endpoint #8e [ 26.787678] usb 1-1.1: Setting params for ep #d (type 0, 12 urbs), ret=0 [ 26.787685] usb 1-1.1: match_endpoint_audioformats: (fmt @6bc43c84) score 2 [ 26.787745] usb 1-1.1: Setting params for ep #8e (type 0, 12 urbs), ret=0 [ 26.787751] usb 1-1.1: Starting data EP @a14130b5 [ 26.788420] usb 1-1.1: Starting sync EP @720fb7cf
Note the "Starting sync EP".
Mike
On Wed, Oct 14, 2020 at 9:35 AM Mailing Lists maillist@superlative.org wrote:
On Wed, 14 Oct 2020 at 17:12, Mike Oliphant oliphant@nostatic.org wrote:
Keith - are you getting an implicit feedback endpoint created when you run with the patch?
Hi Mike,
It appears that I do. For reference I'm on kernel 5.4.0-51:
Bus 001 Device 007: ID 0582:01d6 Roland Corp. GT-1 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 255 bMaxPacketSize0 64 idVendor 0x0582 Roland Corp. idProduct 0x01d6 bcdDevice 0.00 iManufacturer 1 BOSS iProduct 2 GT-1 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x00bc bNumInterfaces 4 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 2 iInterface 0 ** UNRECOGNIZED: 06 24 f1 01 00 00 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 2 iInterface 0 ** UNRECOGNIZED: 07 24 01 01 00 01 00 ** UNRECOGNIZED: 0b 24 02 01 02 04 18 01 44 ac 00 ** UNRECOGNIZED: 06 24 f1 04 16 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x0d EP 13 OUT bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x0038 1x 56 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 1 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 1 iInterface 0 ** UNRECOGNIZED: 07 24 01 07 00 01 00 ** UNRECOGNIZED: 0b 24 02 01 02 04 18 01 44 ac 00 ** UNRECOGNIZED: 06 24 f1 04 16 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x8e EP 14 IN bmAttributes 37 Transfer Type Isochronous Synch Type Asynchronous Usage Type Implicit feedback Data wMaxPacketSize 0x0038 1x 56 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 3 bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 06 24 f1 02 01 01 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 3 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 4 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 4 Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 255 bMaxPacketSize0 64 bNumConfigurations 1 can't get debug descriptor: Resource temporarily unavailable Device Status: 0x0001 Self Powered
-- Keith A Milner
That's also what I see from dmesg when I use the quirk device ID patch. I'm pretty sure it means that implicit feedback is not being enabled for your device.
Since these devices are designed to work with implicit feedback, the ideal solution would be to have them work by using it, rather than disabling it.
That said, patching the quirk code with the extra device IDs would make it so they at least produce output...
The "fix" I'm currently using (linked to in my first response) makes the implicit feedback code not wait to send data until it has received some. It works perfectly for me, but success has been mixed for others so I didn't feel comfortable submitting it as a patch.
FYI, I did a little write-up here:
http://blog.nostatic.org/2020/01/getting-boss-gt-1-effects-processor-to.html
It outlines my struggle with this issue - from trying the quirk ID patch, to messing with the sample rate, and finally to modifying the implicit feedback behavior.
Mike
On Wed, Oct 14, 2020 at 10:23 AM Mailing Lists maillist@superlative.org wrote:
Hi Mike, I'm getting this:
[Oct14 18:21] snd_usb_audio:set_format: usb 1-4: setting usb interface 1:1 [ +0.000003] snd_usb_audio:snd_usb_add_endpoint: usb 1-4: Re-using EP d in iface 1,1 @00000000d0aa6911 [ +0.000018] snd_usb_audio:snd_usb_endpoint_set_params: usb 1-4: Setting params for ep #d (type 0, 3 urbs), ret=0 [ +0.000002] snd_usb_audio:start_endpoints: usb 1-4: Starting data EP @00000000d0aa6911
Cheers,
Keith
On Wed, 14 Oct 2020 at 17:46, Mike Oliphant oliphant@nostatic.org wrote:
Hi Keith,
The lsusb output just shows that the endpoint is there, but not that it is getting connected when the device is initialized. Can you check dmesg output when you use the device for playback?
This is what I see from dmesg when the implicit feedback endpoint is being used:
[ 26.787360] usb 1-1.1: setting usb interface 1:1 [ 26.787367] Creating new playback data endpoint #d [ 26.787375] Creating new capture data endpoint #8e [ 26.787678] usb 1-1.1: Setting params for ep #d (type 0, 12 urbs), ret=0 [ 26.787685] usb 1-1.1: match_endpoint_audioformats: (fmt @6bc43c84) score 2 [ 26.787745] usb 1-1.1: Setting params for ep #8e (type 0, 12 urbs), ret=0 [ 26.787751] usb 1-1.1: Starting data EP @a14130b5 [ 26.788420] usb 1-1.1: Starting sync EP @720fb7cf
Note the "Starting sync EP".
Mike
On Wed, Oct 14, 2020 at 9:35 AM Mailing Lists maillist@superlative.org wrote:
On Wed, 14 Oct 2020 at 17:12, Mike Oliphant oliphant@nostatic.org wrote:
Keith - are you getting an implicit feedback endpoint created when you run with the patch?
Hi Mike,
It appears that I do. For reference I'm on kernel 5.4.0-51:
Bus 001 Device 007: ID 0582:01d6 Roland Corp. GT-1 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 255 bMaxPacketSize0 64 idVendor 0x0582 Roland Corp. idProduct 0x01d6 bcdDevice 0.00 iManufacturer 1 BOSS iProduct 2 GT-1 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x00bc bNumInterfaces 4 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 2 iInterface 0 ** UNRECOGNIZED: 06 24 f1 01 00 00 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 2 iInterface 0 ** UNRECOGNIZED: 07 24 01 01 00 01 00 ** UNRECOGNIZED: 0b 24 02 01 02 04 18 01 44 ac 00 ** UNRECOGNIZED: 06 24 f1 04 16 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x0d EP 13 OUT bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x0038 1x 56 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 1 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 1 iInterface 0 ** UNRECOGNIZED: 07 24 01 07 00 01 00 ** UNRECOGNIZED: 0b 24 02 01 02 04 18 01 44 ac 00 ** UNRECOGNIZED: 06 24 f1 04 16 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x8e EP 14 IN bmAttributes 37 Transfer Type Isochronous Synch Type Asynchronous Usage Type Implicit feedback Data wMaxPacketSize 0x0038 1x 56 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 3 bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 06 24 f1 02 01 01 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 3 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 4 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 4 Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 255 bMaxPacketSize0 64 bNumConfigurations 1 can't get debug descriptor: Resource temporarily unavailable Device Status: 0x0001 Self Powered
-- Keith A Milner
--
Keith A Milner
I thought I would re-try the change you made. When I tried this last year on my old laptop, I recall I couldn't get it working properly.
This time around it works... sort of, but isn't without some significant issues for me. For a start, it only works in Jack. If I try to access the alsa device directly (for instance, using ALSA mode in Ardour or using Audacity) it doesn't work. It also fills my dmesg with error messages:
[ 184.089158] usb 1-4: Unable to change format on ep #8e: already in use [ 184.089232] usb 1-4: Unable to change format on ep #8e: already in use [ 184.089401] usb 1-4: Unable to change format on ep #8e: already in use [ 184.089619] usb 1-4: Unable to change format on ep #8e: already in use
So, unfortunately, whilst it seems like it's a tactical fix for some situations, it seems to be broken in other ways.
When I tried it on my GT-001 I got similar results, although only one "Unable to change format on ep #8e: already in use" message this time rather than the logs getting spammed. Interestingly, I got more xruns with this as well.
Personally I'll be going back to how I had it before with the implicit feedback disabled, as it's more reliable and functional for me, but it's clear this one isn't solved yet.
Cheers,
Keith
On Wed, 14 Oct 2020 at 19:17, Mike Oliphant oliphant@nostatic.org wrote:
That's also what I see from dmesg when I use the quirk device ID patch. I'm pretty sure it means that implicit feedback is not being enabled for your device.
Since these devices are designed to work with implicit feedback, the ideal solution would be to have them work by using it, rather than disabling it.
That said, patching the quirk code with the extra device IDs would make it so they at least produce output...
The "fix" I'm currently using (linked to in my first response) makes the implicit feedback code not wait to send data until it has received some. It works perfectly for me, but success has been mixed for others so I didn't feel comfortable submitting it as a patch.
FYI, I did a little write-up here:
http://blog.nostatic.org/2020/01/getting-boss-gt-1-effects-processor-to.html
It outlines my struggle with this issue - from trying the quirk ID patch, to messing with the sample rate, and finally to modifying the implicit feedback behavior.
Mike
On Wed, Oct 14, 2020 at 10:23 AM Mailing Lists maillist@superlative.org wrote:
Hi Mike, I'm getting this:
[Oct14 18:21] snd_usb_audio:set_format: usb 1-4: setting usb interface 1:1 [ +0.000003] snd_usb_audio:snd_usb_add_endpoint: usb 1-4: Re-using EP d in iface 1,1 @00000000d0aa6911 [ +0.000018] snd_usb_audio:snd_usb_endpoint_set_params: usb 1-4: Setting params for ep #d (type 0, 3 urbs), ret=0 [ +0.000002] snd_usb_audio:start_endpoints: usb 1-4: Starting data EP @00000000d0aa6911
Cheers,
Keith
On Wed, 14 Oct 2020 at 17:46, Mike Oliphant oliphant@nostatic.org wrote:
Hi Keith,
The lsusb output just shows that the endpoint is there, but not that it is getting connected when the device is initialized. Can you check dmesg output when you use the device for playback?
This is what I see from dmesg when the implicit feedback endpoint is being used:
[ 26.787360] usb 1-1.1: setting usb interface 1:1 [ 26.787367] Creating new playback data endpoint #d [ 26.787375] Creating new capture data endpoint #8e [ 26.787678] usb 1-1.1: Setting params for ep #d (type 0, 12 urbs), ret=0 [ 26.787685] usb 1-1.1: match_endpoint_audioformats: (fmt @6bc43c84) score 2 [ 26.787745] usb 1-1.1: Setting params for ep #8e (type 0, 12 urbs), ret=0 [ 26.787751] usb 1-1.1: Starting data EP @a14130b5 [ 26.788420] usb 1-1.1: Starting sync EP @720fb7cf
Note the "Starting sync EP".
Mike
On Wed, Oct 14, 2020 at 9:35 AM Mailing Lists maillist@superlative.org wrote:
On Wed, 14 Oct 2020 at 17:12, Mike Oliphant oliphant@nostatic.org wrote:
Keith - are you getting an implicit feedback endpoint created when you run with the patch?
Hi Mike,
It appears that I do. For reference I'm on kernel 5.4.0-51:
Bus 001 Device 007: ID 0582:01d6 Roland Corp. GT-1 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 255 bMaxPacketSize0 64 idVendor 0x0582 Roland Corp. idProduct 0x01d6 bcdDevice 0.00 iManufacturer 1 BOSS iProduct 2 GT-1 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x00bc bNumInterfaces 4 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 2 iInterface 0 ** UNRECOGNIZED: 06 24 f1 01 00 00 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 2 iInterface 0 ** UNRECOGNIZED: 07 24 01 01 00 01 00 ** UNRECOGNIZED: 0b 24 02 01 02 04 18 01 44 ac 00 ** UNRECOGNIZED: 06 24 f1 04 16 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x0d EP 13 OUT bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x0038 1x 56 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 1 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 1 iInterface 0 ** UNRECOGNIZED: 07 24 01 07 00 01 00 ** UNRECOGNIZED: 0b 24 02 01 02 04 18 01 44 ac 00 ** UNRECOGNIZED: 06 24 f1 04 16 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x8e EP 14 IN bmAttributes 37 Transfer Type Isochronous Synch Type Asynchronous Usage Type Implicit feedback Data wMaxPacketSize 0x0038 1x 56 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 3 bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 06 24 f1 02 01 01 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 3 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 4 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 4 Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 255 bMaxPacketSize0 64 bNumConfigurations 1 can't get debug descriptor: Resource temporarily unavailable Device Status: 0x0001 Self Powered
-- Keith A Milner
--
Keith A Milner
Yeah, I think the work-around I found is just that - a solution that works in my particular situation, but does not resolve what seems to be a deeper issue with implicit feedback on these devices.
I'd love to see a real fix, but I haven't had the time to dig more into the code. It would be great to get some input from whoever wrote the implicit feedback system in the first place.
Mike
On Wed, Oct 14, 2020 at 1:57 PM Keith Milner maillist@superlative.org wrote:
I thought I would re-try the change you made. When I tried this last year on my old laptop, I recall I couldn't get it working properly.
This time around it works... sort of, but isn't without some significant issues for me. For a start, it only works in Jack. If I try to access the alsa device directly (for instance, using ALSA mode in Ardour or using Audacity) it doesn't work. It also fills my dmesg with error messages:
[ 184.089158] usb 1-4: Unable to change format on ep #8e: already in use [ 184.089232] usb 1-4: Unable to change format on ep #8e: already in use [ 184.089401] usb 1-4: Unable to change format on ep #8e: already in use [ 184.089619] usb 1-4: Unable to change format on ep #8e: already in use
So, unfortunately, whilst it seems like it's a tactical fix for some situations, it seems to be broken in other ways.
When I tried it on my GT-001 I got similar results, although only one "Unable to change format on ep #8e: already in use" message this time rather than the logs getting spammed. Interestingly, I got more xruns with this as well.
Personally I'll be going back to how I had it before with the implicit feedback disabled, as it's more reliable and functional for me, but it's clear this one isn't solved yet.
Cheers,
Keith
On Wed, 14 Oct 2020 at 19:17, Mike Oliphant oliphant@nostatic.org wrote:
That's also what I see from dmesg when I use the quirk device ID patch. I'm pretty sure it means that implicit feedback is not being enabled for your device.
Since these devices are designed to work with implicit feedback, the ideal solution would be to have them work by using it, rather than disabling it.
That said, patching the quirk code with the extra device IDs would make it so they at least produce output...
The "fix" I'm currently using (linked to in my first response) makes the implicit feedback code not wait to send data until it has received some. It works perfectly for me, but success has been mixed for others so I didn't feel comfortable submitting it as a patch.
FYI, I did a little write-up here:
http://blog.nostatic.org/2020/01/getting-boss-gt-1-effects-processor-to.html
It outlines my struggle with this issue - from trying the quirk ID patch, to messing with the sample rate, and finally to modifying the implicit feedback behavior.
Mike
On Wed, Oct 14, 2020 at 10:23 AM Mailing Lists maillist@superlative.org wrote:
Hi Mike, I'm getting this:
[Oct14 18:21] snd_usb_audio:set_format: usb 1-4: setting usb interface 1:1 [ +0.000003] snd_usb_audio:snd_usb_add_endpoint: usb 1-4: Re-using EP d in iface 1,1 @00000000d0aa6911 [ +0.000018] snd_usb_audio:snd_usb_endpoint_set_params: usb 1-4: Setting params for ep #d (type 0, 3 urbs), ret=0 [ +0.000002] snd_usb_audio:start_endpoints: usb 1-4: Starting data EP @00000000d0aa6911
Cheers,
Keith
On Wed, 14 Oct 2020 at 17:46, Mike Oliphant oliphant@nostatic.org wrote:
Hi Keith,
The lsusb output just shows that the endpoint is there, but not that it is getting connected when the device is initialized. Can you check dmesg output when you use the device for playback?
This is what I see from dmesg when the implicit feedback endpoint is being used:
[ 26.787360] usb 1-1.1: setting usb interface 1:1 [ 26.787367] Creating new playback data endpoint #d [ 26.787375] Creating new capture data endpoint #8e [ 26.787678] usb 1-1.1: Setting params for ep #d (type 0, 12 urbs), ret=0 [ 26.787685] usb 1-1.1: match_endpoint_audioformats: (fmt @6bc43c84) score 2 [ 26.787745] usb 1-1.1: Setting params for ep #8e (type 0, 12 urbs), ret=0 [ 26.787751] usb 1-1.1: Starting data EP @a14130b5 [ 26.788420] usb 1-1.1: Starting sync EP @720fb7cf
Note the "Starting sync EP".
Mike
On Wed, Oct 14, 2020 at 9:35 AM Mailing Lists maillist@superlative.org wrote:
On Wed, 14 Oct 2020 at 17:12, Mike Oliphant oliphant@nostatic.org wrote:
Keith - are you getting an implicit feedback endpoint created when you run with the patch?
Hi Mike,
It appears that I do. For reference I'm on kernel 5.4.0-51:
Bus 001 Device 007: ID 0582:01d6 Roland Corp. GT-1 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 255 bMaxPacketSize0 64 idVendor 0x0582 Roland Corp. idProduct 0x01d6 bcdDevice 0.00 iManufacturer 1 BOSS iProduct 2 GT-1 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x00bc bNumInterfaces 4 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 2 iInterface 0 ** UNRECOGNIZED: 06 24 f1 01 00 00 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 2 iInterface 0 ** UNRECOGNIZED: 07 24 01 01 00 01 00 ** UNRECOGNIZED: 0b 24 02 01 02 04 18 01 44 ac 00 ** UNRECOGNIZED: 06 24 f1 04 16 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x0d EP 13 OUT bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x0038 1x 56 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 1 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 1 iInterface 0 ** UNRECOGNIZED: 07 24 01 07 00 01 00 ** UNRECOGNIZED: 0b 24 02 01 02 04 18 01 44 ac 00 ** UNRECOGNIZED: 06 24 f1 04 16 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x8e EP 14 IN bmAttributes 37 Transfer Type Isochronous Synch Type Asynchronous Usage Type Implicit feedback Data wMaxPacketSize 0x0038 1x 56 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 3 bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 06 24 f1 02 01 01 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 3 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 4 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 4 Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 255 bMaxPacketSize0 64 bNumConfigurations 1 can't get debug descriptor: Resource temporarily unavailable Device Status: 0x0001 Self Powered
-- Keith A Milner
--
Keith A Milner
--
Keith A Milner
On Wed, 14 Oct 2020 23:49:25 +0200, Mike Oliphant wrote:
Yeah, I think the work-around I found is just that - a solution that works in my particular situation, but does not resolve what seems to be a deeper issue with implicit feedback on these devices.
I'd love to see a real fix, but I haven't had the time to dig more into the code. It would be great to get some input from whoever wrote the implicit feedback system in the first place.
The already-in-use error is a long-standing problem of implicit fb implementations. Recently the support for full duplex was introduced and should work in some level, but I'm afraid that it's not perfect. In particular, it may still depend on the order of the device opens.
Unfortunately I have no hardware to test that shows the behavior, so it's a bit tough to debug from my side.
thanks,
Takashi
Mike
On Wed, Oct 14, 2020 at 1:57 PM Keith Milner maillist@superlative.org wrote:
I thought I would re-try the change you made. When I tried this last year on my old laptop, I recall I couldn't get it working properly.
This time around it works... sort of, but isn't without some significant issues for me. For a start, it only works in Jack. If I try to access the alsa device directly (for instance, using ALSA mode in Ardour or using Audacity) it doesn't work. It also fills my dmesg with error messages:
[ 184.089158] usb 1-4: Unable to change format on ep #8e: already in use [ 184.089232] usb 1-4: Unable to change format on ep #8e: already in use [ 184.089401] usb 1-4: Unable to change format on ep #8e: already in use [ 184.089619] usb 1-4: Unable to change format on ep #8e: already in use
So, unfortunately, whilst it seems like it's a tactical fix for some situations, it seems to be broken in other ways.
When I tried it on my GT-001 I got similar results, although only one "Unable to change format on ep #8e: already in use" message this time rather than the logs getting spammed. Interestingly, I got more xruns with this as well.
Personally I'll be going back to how I had it before with the implicit feedback disabled, as it's more reliable and functional for me, but it's clear this one isn't solved yet.
Cheers,
Keith
On Wed, 14 Oct 2020 at 19:17, Mike Oliphant oliphant@nostatic.org wrote:
That's also what I see from dmesg when I use the quirk device ID patch. I'm pretty sure it means that implicit feedback is not being enabled for your device.
Since these devices are designed to work with implicit feedback, the ideal solution would be to have them work by using it, rather than disabling it.
That said, patching the quirk code with the extra device IDs would make it so they at least produce output...
The "fix" I'm currently using (linked to in my first response) makes the implicit feedback code not wait to send data until it has received some. It works perfectly for me, but success has been mixed for others so I didn't feel comfortable submitting it as a patch.
FYI, I did a little write-up here:
http://blog.nostatic.org/2020/01/getting-boss-gt-1-effects-processor-to.html
It outlines my struggle with this issue - from trying the quirk ID patch, to messing with the sample rate, and finally to modifying the implicit feedback behavior.
Mike
On Wed, Oct 14, 2020 at 10:23 AM Mailing Lists maillist@superlative.org wrote:
Hi Mike, I'm getting this:
[Oct14 18:21] snd_usb_audio:set_format: usb 1-4: setting usb interface 1:1 [ +0.000003] snd_usb_audio:snd_usb_add_endpoint: usb 1-4: Re-using EP d in iface 1,1 @00000000d0aa6911 [ +0.000018] snd_usb_audio:snd_usb_endpoint_set_params: usb 1-4: Setting params for ep #d (type 0, 3 urbs), ret=0 [ +0.000002] snd_usb_audio:start_endpoints: usb 1-4: Starting data EP @00000000d0aa6911
Cheers,
Keith
On Wed, 14 Oct 2020 at 17:46, Mike Oliphant oliphant@nostatic.org wrote:
Hi Keith,
The lsusb output just shows that the endpoint is there, but not that it is getting connected when the device is initialized. Can you check dmesg output when you use the device for playback?
This is what I see from dmesg when the implicit feedback endpoint is being used:
[ 26.787360] usb 1-1.1: setting usb interface 1:1 [ 26.787367] Creating new playback data endpoint #d [ 26.787375] Creating new capture data endpoint #8e [ 26.787678] usb 1-1.1: Setting params for ep #d (type 0, 12 urbs), ret=0 [ 26.787685] usb 1-1.1: match_endpoint_audioformats: (fmt @6bc43c84) score 2 [ 26.787745] usb 1-1.1: Setting params for ep #8e (type 0, 12 urbs), ret=0 [ 26.787751] usb 1-1.1: Starting data EP @a14130b5 [ 26.788420] usb 1-1.1: Starting sync EP @720fb7cf
Note the "Starting sync EP".
Mike
On Wed, Oct 14, 2020 at 9:35 AM Mailing Lists maillist@superlative.org wrote:
On Wed, 14 Oct 2020 at 17:12, Mike Oliphant oliphant@nostatic.org wrote:
> Keith - are you getting an implicit feedback endpoint created when > you run with the patch? >
Hi Mike,
It appears that I do. For reference I'm on kernel 5.4.0-51:
Bus 001 Device 007: ID 0582:01d6 Roland Corp. GT-1 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 255 bMaxPacketSize0 64 idVendor 0x0582 Roland Corp. idProduct 0x01d6 bcdDevice 0.00 iManufacturer 1 BOSS iProduct 2 GT-1 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x00bc bNumInterfaces 4 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 2 iInterface 0 ** UNRECOGNIZED: 06 24 f1 01 00 00 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 2 iInterface 0 ** UNRECOGNIZED: 07 24 01 01 00 01 00 ** UNRECOGNIZED: 0b 24 02 01 02 04 18 01 44 ac 00 ** UNRECOGNIZED: 06 24 f1 04 16 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x0d EP 13 OUT bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x0038 1x 56 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 1 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 1 iInterface 0 ** UNRECOGNIZED: 07 24 01 07 00 01 00 ** UNRECOGNIZED: 0b 24 02 01 02 04 18 01 44 ac 00 ** UNRECOGNIZED: 06 24 f1 04 16 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x8e EP 14 IN bmAttributes 37 Transfer Type Isochronous Synch Type Asynchronous Usage Type Implicit feedback Data wMaxPacketSize 0x0038 1x 56 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 3 bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 06 24 f1 02 01 01 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 3 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 4 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 4 Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 255 bMaxPacketSize0 64 bNumConfigurations 1 can't get debug descriptor: Resource temporarily unavailable Device Status: 0x0001 Self Powered
-- Keith A Milner
--
Keith A Milner
--
Keith A Milner
Thanks for the input, Takashi - and I completely understand the difficulty in resolving problems for specific hardware that you don't have available.
Mike
On Thu, Oct 15, 2020 at 5:37 AM Takashi Iwai tiwai@suse.de wrote:
On Wed, 14 Oct 2020 23:49:25 +0200, Mike Oliphant wrote:
Yeah, I think the work-around I found is just that - a solution that
works
in my particular situation, but does not resolve what seems to be a
deeper
issue with implicit feedback on these devices.
I'd love to see a real fix, but I haven't had the time to dig more into
the
code. It would be great to get some input from whoever wrote the implicit feedback system in the first place.
The already-in-use error is a long-standing problem of implicit fb implementations. Recently the support for full duplex was introduced and should work in some level, but I'm afraid that it's not perfect. In particular, it may still depend on the order of the device opens.
Unfortunately I have no hardware to test that shows the behavior, so it's a bit tough to debug from my side.
thanks,
Takashi
Mike
On Wed, Oct 14, 2020 at 1:57 PM Keith Milner maillist@superlative.org wrote:
I thought I would re-try the change you made. When I tried this last
year
on my old laptop, I recall I couldn't get it working properly.
This time around it works... sort of, but isn't without some
significant
issues for me. For a start, it only works in Jack. If I try to access
the
alsa device directly (for instance, using ALSA mode in Ardour or using Audacity) it doesn't work. It also fills my dmesg with error messages:
[ 184.089158] usb 1-4: Unable to change format on ep #8e: already in
use
[ 184.089232] usb 1-4: Unable to change format on ep #8e: already in
use
[ 184.089401] usb 1-4: Unable to change format on ep #8e: already in
use
[ 184.089619] usb 1-4: Unable to change format on ep #8e: already in
use
So, unfortunately, whilst it seems like it's a tactical fix for some situations, it seems to be broken in other ways.
When I tried it on my GT-001 I got similar results, although only one "Unable to change format on ep #8e: already in use" message this time rather than the logs getting spammed. Interestingly, I got more xruns
with
this as well.
Personally I'll be going back to how I had it before with the implicit feedback disabled, as it's more reliable and functional for me, but
it's
clear this one isn't solved yet.
Cheers,
Keith
On Wed, 14 Oct 2020 at 19:17, Mike Oliphant oliphant@nostatic.org
wrote:
That's also what I see from dmesg when I use the quirk device ID
patch.
I'm pretty sure it means that implicit feedback is not being enabled
for
your device.
Since these devices are designed to work with implicit feedback, the ideal solution would be to have them work by using it, rather than disabling it.
That said, patching the quirk code with the extra device IDs would make it so they at least produce output...
The "fix" I'm currently using (linked to in my first response) makes
the
implicit feedback code not wait to send data until it has received
some. It
works perfectly for me, but success has been mixed for others so I
didn't
feel comfortable submitting it as a patch.
FYI, I did a little write-up here:
http://blog.nostatic.org/2020/01/getting-boss-gt-1-effects-processor-to.html
It outlines my struggle with this issue - from trying the quirk ID
patch,
to messing with the sample rate, and finally to modifying the implicit feedback behavior.
Mike
On Wed, Oct 14, 2020 at 10:23 AM Mailing Lists <
maillist@superlative.org>
wrote:
Hi Mike, I'm getting this:
[Oct14 18:21] snd_usb_audio:set_format: usb 1-4: setting usb
interface
1:1 [ +0.000003] snd_usb_audio:snd_usb_add_endpoint: usb 1-4: Re-using
EP d
in iface 1,1 @00000000d0aa6911 [ +0.000018] snd_usb_audio:snd_usb_endpoint_set_params: usb 1-4: Setting params for ep #d (type 0, 3 urbs), ret=0 [ +0.000002] snd_usb_audio:start_endpoints: usb 1-4: Starting data
EP
@00000000d0aa6911
Cheers,
Keith
On Wed, 14 Oct 2020 at 17:46, Mike Oliphant oliphant@nostatic.org wrote:
Hi Keith,
The lsusb output just shows that the endpoint is there, but not
that it
is getting connected when the device is initialized. Can you check
dmesg
output when you use the device for playback?
This is what I see from dmesg when the implicit feedback endpoint is being used:
[ 26.787360] usb 1-1.1: setting usb interface 1:1 [ 26.787367] Creating new playback data endpoint #d [ 26.787375] Creating new capture data endpoint #8e [ 26.787678] usb 1-1.1: Setting params for ep #d (type 0, 12
urbs),
ret=0 [ 26.787685] usb 1-1.1: match_endpoint_audioformats: (fmt
@6bc43c84)
score 2 [ 26.787745] usb 1-1.1: Setting params for ep #8e (type 0, 12
urbs),
ret=0 [ 26.787751] usb 1-1.1: Starting data EP @a14130b5 [ 26.788420] usb 1-1.1: Starting sync EP @720fb7cf
Note the "Starting sync EP".
Mike
On Wed, Oct 14, 2020 at 9:35 AM Mailing Lists <
maillist@superlative.org>
wrote:
> On Wed, 14 Oct 2020 at 17:12, Mike Oliphant <oliphant@nostatic.org
> wrote: > >> Keith - are you getting an implicit feedback endpoint created when >> you run with the patch? >> > > Hi Mike, > > It appears that I do. For reference I'm on kernel 5.4.0-51: > > Bus 001 Device 007: ID 0582:01d6 Roland Corp. GT-1 > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 2.00 > bDeviceClass 255 Vendor Specific Class > bDeviceSubClass 0 > bDeviceProtocol 255 > bMaxPacketSize0 64 > idVendor 0x0582 Roland Corp. > idProduct 0x01d6 > bcdDevice 0.00 > iManufacturer 1 BOSS > iProduct 2 GT-1 > iSerial 0 > bNumConfigurations 1 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 0x00bc > bNumInterfaces 4 > bConfigurationValue 1 > iConfiguration 0 > bmAttributes 0xc0 > Self Powered > MaxPower 0mA > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 0 > bAlternateSetting 0 > bNumEndpoints 0 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 255 Vendor Specific Subclass > bInterfaceProtocol 0 > iInterface 0 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 1 > bAlternateSetting 0 > bNumEndpoints 0 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 2 > bInterfaceProtocol 2 > iInterface 0 > ** UNRECOGNIZED: 06 24 f1 01 00 00 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 1 > bAlternateSetting 1 > bNumEndpoints 1 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 2 > bInterfaceProtocol 2 > iInterface 0 > ** UNRECOGNIZED: 07 24 01 01 00 01 00 > ** UNRECOGNIZED: 0b 24 02 01 02 04 18 01 44 ac 00 > ** UNRECOGNIZED: 06 24 f1 04 16 00 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x0d EP 13 OUT > bmAttributes 5 > Transfer Type Isochronous > Synch Type Asynchronous > Usage Type Data > wMaxPacketSize 0x0038 1x 56 bytes > bInterval 1 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 2 > bAlternateSetting 0 > bNumEndpoints 0 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 2 > bInterfaceProtocol 1 > iInterface 0 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 2 > bAlternateSetting 1 > bNumEndpoints 1 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 2 > bInterfaceProtocol 1 > iInterface 0 > ** UNRECOGNIZED: 07 24 01 07 00 01 00 > ** UNRECOGNIZED: 0b 24 02 01 02 04 18 01 44 ac 00 > ** UNRECOGNIZED: 06 24 f1 04 16 00 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x8e EP 14 IN > bmAttributes 37 > Transfer Type Isochronous > Synch Type Asynchronous > Usage Type Implicit feedback Data > wMaxPacketSize 0x0038 1x 56 bytes > bInterval 1 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 3 > bAlternateSetting 0 > bNumEndpoints 2 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 3 > bInterfaceProtocol 0 > iInterface 0 > ** UNRECOGNIZED: 06 24 f1 02 01 01 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x03 EP 3 OUT > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0200 1x 512 bytes > bInterval 1 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x84 EP 4 IN > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0200 1x 512 bytes > bInterval 0 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 3 > bAlternateSetting 1 > bNumEndpoints 2 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 3 > bInterfaceProtocol 0 > iInterface 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x03 EP 3 OUT > bmAttributes 3 > Transfer Type Interrupt > Synch Type None > Usage Type Data > wMaxPacketSize 0x0200 1x 512 bytes > bInterval 4 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x85 EP 5 IN > bmAttributes 3 > Transfer Type Interrupt > Synch Type None > Usage Type Data > wMaxPacketSize 0x0200 1x 512 bytes > bInterval 4 > Device Qualifier (for other device speed): > bLength 10 > bDescriptorType 6 > bcdUSB 2.00 > bDeviceClass 255 Vendor Specific Class > bDeviceSubClass 0 > bDeviceProtocol 255 > bMaxPacketSize0 64 > bNumConfigurations 1 > can't get debug descriptor: Resource temporarily unavailable > Device Status: 0x0001 > Self Powered > > > -- > Keith A Milner >
--
Keith A Milner
--
Keith A Milner
participants (5)
-
Keith Milner -
Mailing Lists
-
Mike Oliphant -
Szabolcs Szőke -
Takashi Iwai