Created attachment 255707 [details]
aplay --dump-hw-params and arecord --dump-hw-params

Created attachment 255709 [details]
speaker-test with plughw: and hw: addressing

Created attachment 255711 [details]
Verbose aplay attempt of /dev/zero

Note that it takes 20s to time out with the error. While this should play back silence for 1s.

Created attachment 255713 [details]
lsusb -vvv of the device

EP 13 OUT and EP 14 IN are the PCM endpoints.

Created attachment 255715 [details]
Attempting to use the device to Jack

Created attachment 255717 [details]
KATANA-100 block diagram

The owners manual can be found at https://www.boss.info/global/support/by_product/katana-100/owners_manuals/

This screenshot is a block diagram from the manual that helps conceptualize why 2x stereo duplex makes sense and 1x 4 channel duplex doesn't.

Created attachment 255719 [details]
/proc/asound/KATANA/stream0

Since the v3 firmware was released, I tested again.

Boss KATANA 100 Firmware version: 3.01,
Linux Kernel version: 4.18 low latency.

The same issue still persists.

Might be a shot in the dark, but people (including myself) have gotten several Boss/Roland devices working after patching and compiling the kernel ourself.

It seems that many of the products from Boss/Roland use the exact same type of “IN/END points handling”. I don’t have the katana myself and aren’t able to test it. But I would start looking into it and read this thread. It’s full of useful information.

https://linuxmusicians.com/viewtopic.php?f=6&t=17180&p=107252#p107252

Thanks for the pointer! I was able to make my Katana work under Ubuntu 18.10 running the 4.18.0 kernel by adding this to sound/usb/pcm.c:355

>       case USB_ID(0x0582, 0x01d8):
>               return 0;

With these changes, I was able to record and play back through my amp with Jack. Thanks for the tip!

(In reply to szszoke from comment #10)
> Thanks for the pointer! I was able to make my Katana work under Ubuntu 18.10
> running the 4.18.0 kernel by adding this to sound/usb/pcm.c:355
> 
> >       case USB_ID(0x0582, 0x01d8):
> >               return 0;
> 
> With these changes, I was able to record and play back through my amp with
> Jack. Thanks for the tip!

You’re welcome. I suspected it was the same problem. We need more focus on this. Back at kernel 3.10 Roland/Boss devices was working perfectly fine out of the box. I know several people had tried reporting these errors, but apparently pro audio is not a high priority. I recommend compiling as module because it is much much faster than compiling full kernel every time you update. I use rolling release distros and update kernel often.

I ended up doing exactly that.

Could either of you just submit the fix patch?  I'd happily apply the fix.

I can, but there are some things to consider:
1. This workaround works for multiple devices, but we need to hard-code the the USB identifiers.
2. According to the person who discovered this fix, it's a dirty hack that just hides the real problem

I will reach out to the original author and maybe he can explain this better.

Any new information on what could get this from a hack to a suitable patch?

I wrote in on the forum thread but I got no response so far.

I was thinking and hack or not, other devices are using this technique already, so I don't see why couldn't we use it for the Katana.

Takashi Iwai, if your offer still stands, I would like to help with submitting a fix.

I submitted a small patch with the fix.

(In reply to szszoke from comment #18)
> I submitted a small patch with the fix.

I have an issue with M-Audio C400, it's not recognized by JACK on Ubuntu(all versions) after this patch was submitted.

It's appear with no controls on ALSA mixer.

Can you post the output of lsusb? This patch should only affect devices that have this USB vendor and product ID: 0582:01d8.

(In reply to szszoke from comment #20)
> Can you post the output of lsusb? This patch should only affect devices that
> have this USB vendor and product ID: 0582:01d8.

This is my device:

Bus 001 Device 002: ID 0763:2030 Midiman

Your device should not be affected by the patch that was submitted to make the KATANA amps work, but you can try and undo this change: https://github.com/torvalds/linux/commit/7571b6a17fcc5e4f6903f065a82d0e38011346ed

This is the only change that was submitted.

Let me know if you need help with compiling the kernel.

(In reply to szszoke from comment #22)
> Your device should not be affected by the patch that was submitted to make
> the KATANA amps work, but you can try and undo this change:
> https://github.com/torvalds/linux/commit/
> 7571b6a17fcc5e4f6903f065a82d0e38011346ed
> 
> This is the only change that was submitted.
> 
> Let me know if you need help with compiling the kernel.

I really don't know if this patch affected me, but after the release of the kernel with this patch, i'm getting this error, maybe something else has causing this.

I'm using XanMod kernel, version 5.3.8, in any version above, i'm getting this error.

I'm trying with Liquorix too, last version working is 5.3.0-10-1.

Even with last Ubuntu mainline kernel, 5.4.0, it happen.

Can you help-me anyway?

I recompiled the kernel without this patch for KATANA but still get the issue.

I had tried with XanMod 5.3.8.

Would it be possible to have the fix also applied for other Boss devices?
Mine is a GT-001 and on USB it reports ID 0582:01e5 Roland Corp.
So currently I keep on compiling the fix for snd-usb-audio myself to make it work.
Thank you in advance.

Yes, in fact I'm working on a patch that would make the SY-300 synth pedal work with this exact method.

Thanks again for your efforts and I am looking forward to it.

I just wanted to add that the Boss GT-1 (which is different from the GT-001) has this problem as well.

Boss GT-1 USB ID: 0582:01d6

Without the fix, recording and playback are not possible. With the fix, recording and playback work, although I'm getting frequent sample dropouts. Still, working with dropouts is better than not working at all.

I now have what I believe is a better fix, at least for the GT-1. I have implicit feedback working, rather than just being disabled (which is what the previous Katana patch does). I now get perfectly solid capture/playback with no dropouts.

I plan to submit a patch, but I suspect this fix will work for other Boss devices (Katana, GT-001, etc.), so I'd like to cover them if it does.

If you have a Boss device with this issue and are set up to recompile your kernel, drop me an email.

(In reply to Mike Oliphant from comment #29)
> If you have a Boss device with this issue and are set up to recompile your
> kernel, drop me an email.

Hi Mike, I have an RC-202 and I'm set up to recompile, if you want to post the patches somewhere.

Hi Chris - I did a write-up on the process here:

http://blog.nostatic.org/2020/01/getting-boss-gt-1-effects-processor-to.html

got the USB interface of my Boss AD-10 working with the following patch:

-----
--- sound/usb/pcm.c  2020-05-28 22:24:35.623969551 +0200
+++ sound/usb/pcm.c.patched  2020-05-28 22:25:49.092449899 +0200
@@ -369,7 +369,8 @@
 
                alts = &iface->altsetting[1];
                goto add_sync_ep;
-
+    case USB_ID(0x0582, 0x0203): /* BOSS AD10 */
+        return 0;
        }
        if (attr == USB_ENDPOINT_SYNC_ASYNC &&
            altsd->bInterfaceClass == USB_CLASS_VENDOR_SPEC &&
-----

Running kernel 5.7 on Debian Unstable and still cannot seem to get the USB interface working on the Katana. Output works fine, but input doesn't. In Audacity, for example, hitting record doesn't do anything. The bar doesn't move. However, if I set my output to the Katana and play a random bit of noise out of it, it will miraculously start recording. Regardless of whether or not it starts recording, however, Fx FloorBoard can't seem to recognise the device at all.

It works fine under Windows, but every single distribution of Linux I've tried has had the same issue: Debian Unstable (5.6 and 5.7), Ubuntu 18.04 (5.3), Fedora 32 (5.6), and Ubuntu 20.04 (5.4).

I used udev to grant full permissions on the USB device for my user without luck. I also disabled USB autosuspend in case that was affecting it, but it also didn't do anything.

Anyone know of anything that might fix it?

Oh, I should mention I've tried a Katana 50 MkI and a Katana 100 MkII. Both experience the same issues. I've also tried a new cable.

These Boss devices are designed to use the USB path as a continuous input/output channel, with the input fed back to the output after potential processing - basically the way ASIO drivers work in Windows. They seem to require the output to be connected and active for the input to work.

(In reply to Mike Oliphant from comment #35)
> These Boss devices are designed to use the USB path as a continuous
> input/output channel, with the input fed back to the output after potential
> processing - basically the way ASIO drivers work in Windows. They seem to
> require the output to be connected and active for the input to work.

Ah, I see. Is there any way to set it as a "pseudo output"? Setting it as a system-wide output gives me the jumps when I get a notification, for example, because it's put through all the amp's effects. And, trust me, heavily distorted, delay-ridden ping sounds from Telegram are are absolutely terrifying.

This should now be fixed in the kernel, at least for the BOSS BR-80, GT-100, GT-001, and Katana (and the GT-1, as soon as a recent patch makes its way in).

I suspect it will work for other devices as well - the relevant USB IDs would just need to be added here:

https://github.com/torvalds/linux/blob/master/sound/usb/implicit.c

(In reply to Mike Oliphant from comment #37)
> This should now be fixed in the kernel, at least for the BOSS BR-80, GT-100,
> GT-001, and Katana (and the GT-1, as soon as a recent patch makes its way
> in).
> 
> I suspect it will work for other devices as well - the relevant USB IDs
> would just need to be added here:
> 
> https://github.com/torvalds/linux/blob/master/sound/usb/implicit.c

Christmas has come early this year!!!! Which kernel version has this/will this land in?

It just recently hit the mainline kernel tree. Not sure when it will make it out to various distros.

As the patches went into 5.11-rc1, let's close this bug.

To those being able to verify with the latest kernel/patches:

Are you able to use 48kHz with jack with the fixes?

(with kernel 5.9, no matter what I request with jack, the device is set to 44.1kHz) (works in that mode, I can capture audio/send audio to it - but I need 48kHz)

(In reply to Christian Lohmaier from comment #41)
> To those being able to verify with the latest kernel/patches:
> 
> Are you able to use 48kHz with jack with the fixes?
> 
> (with kernel 5.9, no matter what I request with jack, the device is set to
> 44.1kHz) (works in that mode, I can capture audio/send audio to it - but I
> need 48kHz)

I could be wrong, but I think it's probably a limitation of the device itself.  If you're talking about the Katana, the first post seems to agree with what you've found:

> Parameters under Windows 10:
> - 3 Duplex MIDI ports (KATANA, KATANA DAW CTRL, KATANA CTRL)
> - 2 Duplex PCM devices, 2 channels 44.1khz 16/24 bits (PRIMARY, SECONDARY)
> 
> Parameters under Linux:
> - 3 Duplex MIDI ports (KATANA 1, KATANA 2, KATANA 3)
> - 1 Duplex PCM device, 4 channels 44.1khz 32 bits (KATANA)

A workaround might be to tell jack to use the alsa device with "plughw:" preceding the name (or card number), instead of just the "hw:" that's probably preceding the name/card number normally.  That may allow jack to start in 48 kHz, but it won't actually mean your capture would grab more information than the 44.1 kHz samples.  But, it should provide a translation to your desired sample rate of 48 kHz and allow saving in that format.

I hope that helps!

(In reply to Lucas Endres from comment #42)
> (In reply to Christian Lohmaier from comment #41)
> > 
> > Are you able to use 48kHz with jack with the fixes?
> […]
> I could be wrong, but I think it's probably a limitation of the device
> itself.

Nope, can use 44.1kHz, 48kHz and 96kHz without issues on both Windows as well as macOS with the Katana

> A workaround might be to tell jack to use the alsa device with "plughw:"
> preceding the name (or card number),

Didn't manage to get that to work with jack itself. Missing the magic sauce to create a ctrl device for jack. plughw works to add software resampling step with plain alsa - but I couldn't manage to get it to work with jack.
The hardware definitely supports it natively and there should be no need for a software resample step.

(In reply to Christian Lohmaier from comment #43)
> Nope, can use 44.1kHz, 48kHz and 96kHz without issues on both Windows as
> well as macOS with the Katana

Okay, that's good to know!  Mike Oliphant has been active recently tweaking this, having noticed noise using it as a playback device.  I wonder if it would add your extra sample rates: https://patchwork.kernel.org/project/alsa-devel/patch/20210414083255.9527-1-tiwai@suse.de/

> > A workaround might be to tell jack to use the alsa device with "plughw:"
> > preceding the name (or card number),
> 
> Didn't manage to get that to work with jack itself. Missing the magic sauce
> to create a ctrl device for jack. plughw works to add software resampling
> step with plain alsa - but I couldn't manage to get it to work with jack.
> The hardware definitely supports it natively and there should be no need for
> a software resample step.

Now that I know the BOSS Katana is capable of the other sample rates, this is probably moot: In qjackctl, when I go to Setup>Settings->Advanced, there are the the "Output Device" and "Input Device" visible.  It is there, that plughw:KATANA would go.

I hope that helps at least somewhat.

tried the plughw method again, but no cigar, no matter whether I set it on the settings tab or individually for input/output on the advanced settings, alsa complains:

creating alsa driver ... plughw:KATANA|plughw:KATANA|256|3|48000|0|0|nomon|swmeter|-|32bit
configuring for 48000Hz, period = 256 frames (5.3 ms), buffer = 3 periods
ALSA: final selected sample format for capture: 32bit float little-endian
You appear to be using the ALSA software "plug" layer, probably
a result of using the "default" ALSA device. This is less
efficient than it could be. Consider using a hardware device
instead rather than using the plug layer. Usually the name of the
hardwa
ALSA: cannot set period size to 256 frames for capture
ALSA: cannot configure capture channel
Jack: JackDriver::Close

no matter what period size always the same error.

Also tried the patch on 5.11.6, but that unfortunately didn't change anything, still the samplerate gets locked to 44100Hz

Appreciate the help and pointers though.

(In reply to Christian Lohmaier from comment #45)
> tried the plughw method again, but no cigar, no matter whether I set it on
> the settings tab or individually for input/output on the advanced settings,
> alsa complains:
> 
> creating alsa driver ...
> plughw:KATANA|plughw:KATANA|256|3|48000|0|0|nomon|swmeter|-|32bit
> configuring for 48000Hz, period = 256 frames (5.3 ms), buffer = 3 periods
> ALSA: final selected sample format for capture: 32bit float little-endian
> You appear to be using the ALSA software "plug" layer, probably
> a result of using the "default" ALSA device. This is less
> efficient than it could be. Consider using a hardware device
> instead rather than using the plug layer. Usually the name of the
> hardwa
> ALSA: cannot set period size to 256 frames for capture
> ALSA: cannot configure capture channel
> Jack: JackDriver::Close
> 
> no matter what period size always the same error.
> 
> Also tried the patch on 5.11.6, but that unfortunately didn't change
> anything, still the samplerate gets locked to 44100Hz
> 
> Appreciate the help and pointers though.

That's interesting.  I just tested it on my EDIROL UA-4FX and it jack started properly for me, even though I still had the warning you did.

13:16:44.160 JACK is starting...
13:16:44.160 /usr/bin/jackd -P80 -dalsa -r96000 -p512 -n3 -D -Cplughw:UA4FX -Pplughw:UA4FX
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
13:16:44.169 JACK was started with PID=92169.
no message buffer overruns
no message buffer overruns
no message buffer overruns
jackdmp 1.9.16
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2016 Grame.
Copyright 2016-2020 Filipe Coelho.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK server starting in realtime mode with priority 80
self-connect-mode is "Don't restrict self connect requests"
audio_reservation_init
Acquire audio card Audio2
creating alsa driver ... plughw:UA4FX|plughw:UA4FX|512|3|96000|0|0|nomon|swmeter|-|32bit
configuring for 96000Hz, period = 512 frames (5.3 ms), buffer = 3 periods
ALSA: final selected sample format for capture: 32bit float little-endian
You appear to be using the ALSA software "plug" layer, probably
a result of using the "default" ALSA device. This is less
efficient than it could be. Consider using a hardware device
instead rather than using the plug layer. Usually the name of the
hardwa
ALSA: use 3 periods for capture
ALSA: final selected sample format for playback: 32bit float little-endian
You appear to be using the ALSA software "plug" layer, probably
a result of using the "default" ALSA device. This is less
efficient than it could be. Consider using a hardware device
instead rather than using the plug layer. Usually the name of the
hardwa
ALSA: use 3 periods for playback
13:16:46.238 JACK connection change.
13:16:46.238 Server configuration saved
13:16:46.239 Statistics reset.
13:16:46.245 Client activated.
13:16:46.245 Patchbay deactivated.
13:16:46.249 JACK connection graph change.

Maybe your problems are with JACK itself, as I've had trouble with certain versions on my EDIROL devices before, so I've been using debian's jackd2 package.

However, this is just a workaround.  Since you know the KATANA's actual sample rate should work beyond 44100, I would try the latest development patch by Takashi Iwai.  Things are moving fast, and it might be a better fit than what I linked you to earlier, although it could have exactly the same result.  Here's the alsa-devel thread pertaining to it:
https://mailman.alsa-project.org/pipermail/alsa-devel/2021-April/183960.html

Also, in my short experience, that alsa-devel mailing list has been great for getting direct help from people who know much more than I.

Takashi's current patch uses the USB endpoint information read from the device to, hopefully properly, set up any Roland/EDIROL/BOSS device!  Although Mike Oliphant has tested the KATANA to be working with it, it wouldn't hurt have more feedback from you, especially if your experience leads to better solutions.  It is slated to be in kernel 5.13, but is currently a patch to apply to the linux-next branch.  I got that branch from a snapshot at:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/
But, I actually still manually patched implicit.c due to the mix of tabs in the kernel, and spaces in the patch which makes it easier to translate to email (or at least my gmail).

I hope this becomes more than the wild goose chase you've been on so far,

  Lucas