** Latest Update: The Boss GT-1 should be working out of the box as of Linux kernel v5.14.
I recently picked up a Boss GT-1 guitar digital effects floorboard to use directly, and also to play with connecting it up to the Raspberry Pi.
A month later, I have everything working well. As is often the case with niche gear and Linux, though, it was a bumpy road to get there. I'm going to document the process here, in case it is helpful for anyone with a similar issue.
I booted up my Pi, connected the GT-1 via USB, ran lsusb to list the available USB devices, and there it was. Great - that was easy!
Next, I tried playing a .wav file with aplay. No go. No audio at all. Not so great.
Time to start scouring the internet. After a while, I came across this thread on linuxmusicians.com:
https://linuxmusicians.com/viewtopic.php?f=6&t=17180
It had a fix for another Boss device. It also turned out to work for Boss Katana Amplifiers, which have a software setup that is very similar to my GT-1 device.
I grabbed the kernel source code, applied the fix (with a tweak for my device), and soon I had working audio! Well, kind of working. I was getting pops and crackles every second or so - enough to make things unusable.
To understand this fix, and why it wasn't quite working requires a bit of explanation on how USB audio works. There are a number of methods that devices use to synchronize audio timing. The one used by the Boss GT-1 (and many similar devices) is called "implicit feedback". In simple terms, what this does is, on devices that have both a capture and playback that are controlled by the same clock, the capture source is used to determine the output data rate. Essentially, the host is in a USB feedback loop - outputting the same number of samples it receives - generally after doing some processing.
The fix that got my interface working basically disables the implicit feedback mechanism. This got audio moving through the system, but because there was no timing feedback it was slightly off - resulting in the pops and crackles I was experiencing.
A while later, I came across this post in the Line 6 forums about getting the Helix (another guitar processing device) working in Linux:
https://line6.com/support/topic/4426-line-6-with-linux/?tab=comments#comment-240302
The additional fix here was to hack the sample rate slightly to try to match the real timing of the device. I gave it a try, and it turned out that if I nudged the sample rate to 44105 (instead of 44100), my pops and crackles mostly went away - happening every few minutes instead of constantly.
This fix was obviously a hack, and not perfect, but it at least made my interface usable. The core problem still existed - the device should be operating using implicit feedback, but when this was enabled it didn't work at all.
I had posted about these issues on the alsa-devel mailing list, and a while later I got a helpful email suggesting that some Roland devices waited to send capture data until they had received some playback data. The kernel implicit feedback code, on the other hand, was waiting for some capture data before it send any playback data. The result was a standoff - with nothing getting sent either way.
Simply disabling the code that caused playback to wait on capture resulted in working audio with implicit feedback enabled, and a perfectly solid audio stream with no pops or crackles!
I outlined this fix on the alsa-devel mailing list here:
https://mailman.alsa-project.org/pipermail/alsa-devel/2020-January/161951.html
I hope to get a patch for this into the kernel eventually - right now I am doing some poking around to see if I can find out what other similar devices this fix might work for.
** UPDATE **
A series of patches to implicit feedback handling made it into the kernel (5.11) a while back. I had thought that these changes were fully working on the BOSS GT-1, but it turns out that I just hadn't tested well enough.
Audio playback and capture works, but with periodic dropouts. I get the exact same behavior as I did with the quirk to completely disable implicit feedback.
Changing the GT-1 playback feedback handling from IMPLICIT_FB_SKIP_DEV(0x0582, 0x01d6) to IMPLICIT_FB_GENERIC_DEV(0x0582, 0x01d6) and applying the endpoint.c patch outlined earlier in this post results in perfect playback and capture for me.
Here is my post on the alsa-devel mailing list about this:
** UPDATE 4/14/2021 **
A version of the above fix has now been submitted as a patch and should eventually get into the mainline kernel. The fix is also being applied to other BOSS devices, such as the rest of the GT family, and the BOSS Katana. Here is the patch:
** LATEST UPDATE **
The above fix was released with Linux kernel v5.14.
I guess you are Mike? Thanks for this.
ReplyDeleteFollowing the progress eagerly.
The last time I worked on kernel modules was when I fixed the SBLive!
module and supporting apps around 2007.
Thanks a lot for this patch. It makes my Librazik distro much more useful !
ReplyDeleteGlad to hear that it helped!
DeleteHello Mike,
DeleteIt works well as input/output device, but are you able to use a software to control the Gt-1 ? Either « Boss Tone Studio » with wine, or « FxFloorBoard ?
I have no success with the Boss software, because the connection fails.
With FxFloorBoard, it's better : the connection is successful, but there is frequent segmentation faults :( So, it can be used, but not without a lot of patience.
If you have another trick for this problem, it would be great :)
Thanks.
MIDI input was also not working on my GT-1 (although MIDI output *was* working).
DeleteCommenting out this section of "snd_usbmidi_detect_endpoints()" in midi.c:
if (USB_ID_VENDOR(umidi->usb_id) == 0x0582)
snd_usbmidi_switch_roland_altsetting(umidi);
fixed it.
Thanks for your help.
DeleteCould you confirm me that this comment only modifies the module snd-usmidi-lib.ko ?
For now, it doesn't bring anything :( …
Yeah, I think that is the only thing that should be changed. The fix gets midi working for me - I can send/receive sysex messages. I haven't tried to do anything more complicated than that, though.
DeleteOk. The Boss software connects shortly, reads the patchs from the GT-1, and then disconnects… It's a little frustrating, but I have no idea how to do better.
DeleteBut thanks again for your fix, that's good enough :)
At some point I'll do some more work on midi - I'll post any progress here.
DeleteIt would be nice, thanks :)
DeleteHello!
ReplyDeleteThanks so much for the article! Apparently you have found a solution and I want to try it soon. But I don’t know where to start? How to connectBoss GT-1 to Linux? Thanks in advance!
The fix is outlined in the link at the bottom of the post. It requires patching and recompiling your kernel.
DeleteHi Mike, tried your fix (ubuntu 19.10 and GT-1) but it did not work.
ReplyDeleteWhat I mean: the dmesg says it is registered (I dont have the "Unable to change format on ep #8e: already in use" message anymore and I added some print so I can see that it is running the patch (no more implicit feedback and the rate change). But alsamixer does not report play or capture port at all.
Did I understand that only 2 patches are necessary: the one with the USB_ID to return 0 in pcm.c and the one about the rate+5 in set_params?
TIA
Emmanuel
The patches to pcm.c were things I tried along the way. You should not use them. The only patch necessary is the one to endpoint.c outlined here:
Deletehttps://mailman.alsa-project.org/pipermail/alsa-devel/2020-January/161951.html
OK Thx, will try!
DeleteIt does not work: alsamixer don't report playback or capture.
DeleteFWIW the firmware version is 1.08 that might be the difference.
I'm also running the 1.08 firmware. Does the card show up in "aplay -L"? Does playing a .wav file with aplay work?
DeleteHi,
ReplyDeleteI wanted to try your method to get the GT-1 working, but I'm not quite clear on which "if (snd_usb_endpoint_implicit_feedback_sink(ep))" to comment out...
There's one that starts in line 381, but that is not in the function "int snd_usb_endpoint_start(struct snd_usb_endpoint *ep)", that the post in the alsa mailing list seems to refer to.
Then there's one if-block in line 951, which does belong to said function, but commenting it out throws compile errors.
Could you describe the patch a bit more clearly, please?
Thanks for the work you put into this!
The one at 951 is correct. Make sure you comment out the whole if block:
ReplyDeleteif (snd_usb_endpoint_implicit_feedback_sink(ep)) {
for (i = 0; i < ep->nurbs; i++) {
struct snd_urb_ctx *ctx = ep->urb + i;
list_add_tail(&ctx->ready_list, &ep->ready_playback_urbs);
}
return 0;
}
Eh... silly me. Thanks.
DeleteI totally missed the for loop and only commented out until the first }.
You rock. :D
I tried only this, didn't work. With this and "return 0;" from katana, works sometimes. Is a GP-10, not a GT-1. I'm still testing, tried just Alsa, sometimes audacity did not start to record. I'll try with jack soon.
DeleteForget to say I'm using Ubuntu 18, kernel 4.15.0
DeleteDefinitely try it with Jack with both input and output running. I think it might not be able to just record if playback is not also running.
DeleteHi!
ReplyDeleteI wanted to try this fix but i could not figure out how to do it. So, could you explain that step by step in layman's terms? =D Thx
Sorry - there isn't really a layman's solution right now. You have to know how to recompile your kernel.
DeleteI see. But is there any possibility you could share your kernel file with all the necessary changes already patched in? That'd be great!
DeleteThx again o/
Kernels are very system-specific - you really need to compile it yourself for a change like this.
DeleteHi,
ReplyDeletedid you manage to get it into the official kernel releases, yet?
While my patch works for me, results from testing on other systems has been mixed, so I've been reluctant to submit it to the kernel.
DeleteMaster Mike, you are the best!
ReplyDeleteBest to run GT-1 on my Archlinux.
That is a strange error - it sounds like a more general error with accessing USB on your system rather than a specific issue with the GT-1.
ReplyDelete