Saturday, January 25, 2020

Getting the Boss GT-1 effects processor to work in Linux




** NOTE: If you are just looking for my current solution, it is outlined here:



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.

29 comments:

  1. I guess you are Mike? Thanks for this.
    Following the progress eagerly.
    The last time I worked on kernel modules was when I fixed the SBLive!
    module and supporting apps around 2007.

    ReplyDelete
  2. Thanks a lot for this patch. It makes my Librazik distro much more useful !

    ReplyDelete
    Replies
    1. Glad to hear that it helped!

      Delete
    2. Hello Mike,

      It 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.

      Delete
    3. MIDI input was also not working on my GT-1 (although MIDI output *was* working).

      Commenting 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.

      Delete
    4. Thanks for your help.
      Could you confirm me that this comment only modifies the module snd-usmidi-lib.ko ?
      For now, it doesn't bring anything :( …

      Delete
    5. 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.

      Delete
    6. Ok. 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.
      But thanks again for your fix, that's good enough :)

      Delete
    7. At some point I'll do some more work on midi - I'll post any progress here.

      Delete
  3. Hello!
    Thanks 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!

    ReplyDelete
    Replies
    1. The fix is outlined in the link at the bottom of the post. It requires patching and recompiling your kernel.

      Delete
  4. Hi Mike, tried your fix (ubuntu 19.10 and GT-1) but it did not work.
    What 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

    ReplyDelete
    Replies
    1. 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:

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

      Delete
    2. It does not work: alsamixer don't report playback or capture.
      FWIW the firmware version is 1.08 that might be the difference.

      Delete
    3. I'm also running the 1.08 firmware. Does the card show up in "aplay -L"? Does playing a .wav file with aplay work?

      Delete
  5. Hi,
    I 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!

    ReplyDelete
  6. The one at 951 is correct. Make sure you comment out the whole if block:

    if (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;
    }

    ReplyDelete
    Replies
    1. Eh... silly me. Thanks.
      I totally missed the for loop and only commented out until the first }.

      You rock. :D

      Delete
    2. 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.

      Delete
    3. Forget to say I'm using Ubuntu 18, kernel 4.15.0

      Delete
    4. Definitely 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.

      Delete
  7. Hi!
    I 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

    ReplyDelete
    Replies
    1. Sorry - there isn't really a layman's solution right now. You have to know how to recompile your kernel.

      Delete
    2. I see. But is there any possibility you could share your kernel file with all the necessary changes already patched in? That'd be great!
      Thx again o/

      Delete
    3. Kernels are very system-specific - you really need to compile it yourself for a change like this.

      Delete
  8. Hi,
    did you manage to get it into the official kernel releases, yet?

    ReplyDelete
    Replies
    1. 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.

      Delete