I’ve been using a Zoom R24 as an USB audio device for many years. It provides 8 inputs and 2 outputs, plus controller surface capabilities.
Recently I’ve upgraded Fedora 39 to 42 and now I seem to have lost most of the R24.
In Ardour 8.12 I can configure the audio to ALSA and R24 (input and output). I can configure the R24 as a Mackie control surface. But Ardour only sees system/capture_1 and system/capture_2 for input. Likewise, I only have system/playback_1 & 2. It does not seem the see the R24. On the other hand, using the R24 as a control surface works normally.
I tried the Fedora supplied ardour, a self-built ardour, and the ardour from the site but it doesn’t make any difference.
I suspect this has to do with pipewire but I don’t know what buttons to push to get the R24 going again. Your help is appreciated.
When you configure Ardour to use the ALSA backend then pipewire is out of the picture.
Check the card configuration in alsamixer to see how many channels are indicated, perhaps some channels were disabled in a new default for some reason. That could be related to pipewire, perhaps in the standard desktop profile pipewire disables all but two inputs and then the interface stays in that configuration unless you explicitly change it back.
You could verify that might be the case by first changing the card profile to pro-audio in pipewire, then start Ardour using the ALSA backend again. Should be visible in alsamixer if that is the case.
I found a web page which stated that the R24 is not USB Audio Class 2.0 compliant, which might mean that ALSA is using the device in audio class 1.0 mode, meaning 2 channels and 16 bit only.
The question is why it was fully working with the older kernel and not the newer. Seems specific enough that you will have to either look through the ALSA changes yourself, or find someone on the Linux Audio Users mailing list or kernel mailing list who knows.
Well you would want the linux-audio-user mailing list, not the -dev mailing list:)
That being said if the r24 is only 1.0 class compliant, then I would suspect you had a module you were using before, need to figure out which module that is I suppose. Glancing through the USB-AUDIO quirks I don’t see one for the Zoom so I think a dedicated module, however it could be the chipset for the zoom is more generic, not sure. It has been some time, but I believe the output of lsusb may be of some use in determining this.
Also just for grins and giggles, check to make sure you don’t have a second device for the R24 listed you might need to select?
This likely only has to do with MIDI, and probably not what I would focus on right now.
@Majik Yes — I’ve used the R24 as a 8-in/2-out multichannel device for many years. Likewise, the Zoom H2n as a 4-in/2-out device.
It is only after the recent upgrade to Fedora 42 that both devices are crippled to 2-in/2-out devices.
I was running pulseaudio, and Fedora 42 uses pipewire. So that is my main suspicion. But I am a musician, not an audo dev. I’m used to devices working out of the box.
Thanks, didn’t find that with a quick google. It does indeed look like it is a quirk on the standard usb-audio module, so ignore my comments about a dedicated module above.
Neither Pulseadio, nor Pipewire are device drivers. They are audio servers that deal with things like multiplexing and mixing of streams. ALSA is the driver level, and is used by both Pipewire and Pulseaudio (and Jack).
If you are getting messages like this in the system logs:
That is nothing to do with Pipewire, and everything to do with ALSA. You can also use alsamixer to verify what is visible at the driver (ALSA) level.
To me, this looks like a regression in ALSA, possibly caused by the fact that you are using a newer kernel in Fedora 42.
In the meantime, I would try a live usb version of Ubuntu Studio and see what the results are. It may work as expected. When I have used Fedora in the past, it was not as friendly on the audio side of things.
For a long time best audio support required adding an external repository (Planet CCRMA from the Center for Computer Research in Music and Acoustics), but several years ago the main Fedora repository picked up support for the majority of packages which Planet CCRMA had been supplying, and since then the audio and multimedia support has been very good (with the caveat that Fedora will not supply patent encumbered codecs).
However, the goal of Fedora is to always have the most recent software, so it is definitely not the distribution to use if you value consistency more than always having the latest software versions.
I still see reference to Zoom R16/R24 in quirks.c in the 6.15 source tree (Fedora currently has 6.15.3 in the testing repository, I think still 6.14.11 in the main updates repository).
So it appears that if there is a regression, it was not an intentional removal.
The devices I have are class compliant, so I am not sure how you verify that the device was detected and the relevant quirk behavior applied correctly.
I too, have noticed this message in recent kernels (I use an R16). It used to work flawlessly as a USB 2.0 device. Recent kernels (since around 6.6) have made things a bit weird on less powerful machines. I still have full functionality, but on my little laptop that I take to the studio, there has been a lot of instability and performance loss.
I must state that I do not know if that quirk message wasn’t in earlier versions. Maybe it has always been there but kept unnoticed since everything was functional.
After a lot of experimenting, involving restoring old Fedora versions and live-booting Ubuntu Studio, I come to an embarassing conclusion… Hardware.
For experimenting I have a KVM/USB switch and I had inserted the R24 USB cable into that switch. And that turned out to be the problem. After plugging the USB cable directly into the PC (or via a decent USB hub) all channels are there!
