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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxx> wrote: > >> When I tried this change earlier this year on the BOSS GT-1, it enabled >> sound output on the card (which was not previously working), but with >> significant issues. It resulted in frequent pops and crackles - presumably >> because of the loss of synchronization using implicit feedback. >> >> This was the fix that ended up working for me: >> >> >> https://mailman.alsa-project.org/pipermail/alsa-devel/2020-January/161951.html >> >> But maybe something else has changed in the handling of implicit feedback >> since then? >> >> Mike >> >> On Wed, Oct 14, 2020 at 5:17 AM Mailing Lists <maillist@xxxxxxxxxxxxxxx> >> 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@xxxxxxx> 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@xxxxxxxxx> >>>> >>>> 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@xxxxxxxxxxxxxxxx >>>> https://mailman.alsa-project.org/mailman/listinfo/alsa-devel >>>> >>> >>> >>> -- >>> -- >>> Keith A Milner >>> >> > > -- > -- > Keith A Milner >
