Topic: Madiface XT II Channel Count in CC mode

I'm experiencing issues with channel count with my Madiface XT II, similar to the ones described in https://forum.rme-audio.de/viewtopic.php?id=40725. I bought it to be used with both a Mac and a Linux laptop because, according to the specs, all channels should be available in CC mode. However, I see only 52 input and 54 outputs on my (Arch) Linux system. Tried to tweak my Pipewire settings, but it doesn't seem to affect anything. And honestly, it's quite difficult to know what to tweak. Using it in CC mode on my Mac, I notice that you can select between different number of channels in the Audio MIDI Setup. Can you do this in Pipewire somewhere?

2 (edited by emp 2025-06-12 00:07:29)

Re: Madiface XT II Channel Count in CC mode

It would be awesome if someone from RME could respond here and at least explain why on earth there’s a default option NOT to use all channels in CC mode (even on my Mac that is). The default should be all channels available I think.
As I wrote, an important reason for buying this interface was that it explicitly states that all channels are avallable in CC mode (USB 3). They aren’t. So RME: Is it a bug? Are you investigating? Will there be a fix? Or is it intentional? And if so, why?

3

Re: Madiface XT II Channel Count in CC mode

Ask in the Linux community how to change Alternate Settings. The list you see on Mac is that - various Alternate Settings that need to be selected by the Class Compliant compatible OS to use different channel counts on different sample rates.

The reason you see a lower channel number as default is as simple as logical: would the full channel count be default the unit would only support 48 kHz max. This 'default' can not be changed on the unit (AFAIK no device ever built supports such a function).

Regards
Matthias Carstens
RME

4 (edited by emp 2025-06-12 16:44:09)

Re: Madiface XT II Channel Count in CC mode

Ok, thanks for responding. The problem with the Linux community is that most users there aren’t audio professionals. And you get questions like ”why would anyone need that many channels?”.
But I will give it a try for sure.

Re: Madiface XT II Channel Count in CC mode

emp wrote:

Ok, thanks for responding. The problem with the Linux community is that most users there aren’t audio professionals. And you get questions like ”why would anyone need that many channels?”.
But I will give it a try for sure.

From what I am reading on other threads, it appears that altsets that are higher channel count than the minimum one seem to be not working, and causing some distorted audio. Someone tested this on a Digiface and UFX III and could not get it working beyond the smallest altset (32 channels I believe). Here is that thread: https://forum.rme-audio.de/viewtopic.php?id=31000

One thing that may be worth trying:

1. Identify the Device and Available AltsetsList audio devices:    aplay -l    or    arecord -l    (look for something like "card X: Madiface" or "Fireface" or etc).
Note the card name (e.g., "Pro70790682" is the name of my Babyface Pro) and hardware device (e.g., "device 4" or etc).
View supported altsets and their parameters:    cat /proc/asound/<cardname>/stream0    (replace <cardname> with e.g., "Pro70790682").This dumps details like: Altset 1: Up to 94 channels at 44.1/48 kHz, 24-bit.
Altset 2: Fewer channels, maybe different sample rates, etc. Find the mode which has the channel count and sample rate you would like to use.

2. Since lots seem to be using Jack through Pipewire nowadays, maybe try using qjackctl to set your sample rate and max input/output channels to the values of your target altset. Then, in your DAW, set the inputs/outputs to the same values, and try recording/playback on the higher channel numbers. Hopefully you do not experience the distorted audio issue. You can monitor what the interface is doing by the command    watch cat /proc/asound/<cardname>/stream0

It may also be possible using wireplumber config files, or the   wpctl   command to set a default altset, although I do not know if you'd run into the same issues. Or, possibly there's something in the pipewire.conf file which can help. I'll do some more digging, but I strongly suspect that if you run into the same distortion issue at higher altsets, it's an issue specific to how RME interfaces interact with Linux.

6 (edited by fripholm 2026-10-03 18:31:10)

Re: Madiface XT II Channel Count in CC mode

Sorry for resurrecting an old thread.

I just got a new Madiface XT II that I wanted to use on Linux, hoping to get access to all available channels. I'm on MX Linux 25.3 (liquorix kernel v7.2.8) but I've also tried on Debian "Testing" (comes with kernel 7.2.8 as well). I'm using Reaper 7.81.

As mentioned here and in the other thread, not all altsets are working. Altsets 1 and 2 (52/54 vs. 100/102 channels) work at 44.1/48 when Reaper is using ALSA. Altset 3 (196/198 channels of I/O) produces garbled/distorted sound. At 88.2/96 only altset 1 provides clean sound.

I haven't been able to get native Jack to work at all. Pipewire (v1.6.9) and pipewire-jack stumbles over its 128 channel limit and doesn't even create a system audio device when set to the 'Pro Audio' profile. I'm getting a lot of the following in syslog:

2026-10-02T20:21:30.604913+02:00 xxxxxx pipewire[1434]: spa.alsa: hw:0,0c: Channels doesn't match (requested 128, got 196)
2026-10-02T20:21:30.612008+02:00 xxxxxx pipewire[1434]: spa.audioconvert: can't parse format Channel number out of range
2026-10-02T20:21:30.612091+02:00 xxxxxx pipewire[1434]: pw.node: (alsa_input.usb-RME_MADIface_XT__xxxxxxxxxxxxx-00.pro-input-0-512) suspended -> error (Start error: Channel number out of range)

Interestingly, recorded audio on altset 3 is clean without signs of distortion. The problem only seems to apply to playback.

Although 102 playback channels seem plenty, the Madiface's fixed internal channel layout for MADI 1 through 3 makes it impossible to use MADI 3 (coaxial) whose channels start at number 129 at 48k. Unfortunately, one of the devices I was planning to use over MADI does only provide coaxial. When using straight CC routing, access to AES I/O, Analog I/O or the Phones Out is also not possible because they start at channel #191. You have to sacrifice 3 MADI stereo pairs on MADI 1.

As mentioned before, here and in that other thread, RME might not be responsible for this but I wouldn't even know where to start looking for a way to report this to Linux kernel or ALSA 'people' smile

I was missing the quality and reliability of RME gear since I've sold my UFX+ a few years ago (because of its limits with regards to Linux) and I was really looking forward to giving it another try but I'm kinda stuck now...

Any ideas on options going forward or things I could try?

Re: Madiface XT II Channel Count in CC mode

Hey fripholm
When you connect directly to alsa in reaper are you exactly defining your channel count? eg 196 in & 198 out for 44/48khz ,100 in & 102 out for 88/96. If you leave the channel count undefined in reaper it will default to one altset & changing to a samplerate/altset that doesn't match the  channel count of the altset it has defaulted to may result in garbled/distorted sound. On my ufx3 if i set the channels to 34 i can use all samplerates limited to 34 channels, set to 54 channels samplerates 88/96 & 44/48 will work & 192khz will give garbstorted(stick that in ya dataset ai)sound & 94 channels will work at 44/48 but 88/96 & 192 will be garbstorted.
Somewhere around the start of the year pipewire upped their channel count from 64 to 128 but this insufficient for the Madiface XT2 so pipewire-jack wont work for you.
For my setup I remove pipewire-jack & install pipewire-jack-client, jack2 & QjackCtl via my package manager. Making pipewire a jack client so alsa/jack/pipewire instead of alsa/pipewire/pipewire-jack. This  method should avoid pipewires 128 channel limitation.

Re: Madiface XT II Channel Count in CC mode

Thanks for the reply.

AVal1 wrote:

When you connect directly to alsa in reaper are you exactly defining your channel count? eg 196 in & 198 out for 44/48khz ,100 in & 102 out for 88/96.

This is what I've been doing. Just tested this again: 52/54 and 100/102 work fine at 44.1/48kHz. With channel counts set to 196/198, it garbstorts (I had to pick that up big_smile).

Setting the sample rate to 44.1k initially killed the sound completely. I had to restart Reaper and the device twice before it worked. Don't know what's happening there.

Higher sample rates are similar. Not all altsets are working.

I've already tried to use native jack to work around the pipewire channel limit but I didn't get Qjackctl to register the device and gave up. Jack still uses ALSA as a backend and if native alsa doesn't work properly, jack won't either - I think.

For now, I'm about to return the Madiface as using Windows (or Mac) is not an option. It's a pity. I guess, I'm gonna try again in a few years... sad

Re: Madiface XT II Channel Count in CC mode

hi,
regarding your syslog with pw… pw asks ALSA for 128 channels (its own maximum). ALSA answers with 196, which is the valid altset 3 configuration. then pw throws the "Channels doesn't match (requested 128, got 196)" and takes over the 196:
https://github.com/PipeWire/pipewire/bl … cm.c#L2368

in short: pw is limited to 128 channels.

however, the distortion is another thing.
did you check the altset capabilities as gaw0319 described here? https://forum.rme-audio.de/viewtopic.ph … h%20trying

the output would help to overthink what might be the issue as i don’t own a madiface xt ii

“Do It For Her”
My Gear: Bontempi Magic light Keyboard

10 (edited by fripholm 2026-10-07 11:42:25)

Re: Madiface XT II Channel Count in CC mode

maggie33 wrote:

did you check the altset capabilities as gaw0319 described here? https://forum.rme-audio.de/viewtopic.ph … h%20trying

Yes, I checked that. Here's the output on altset 3 (I/O = 196/198) at 48kHz:

RME MADIface XT (xxxxxxxx) at usb-0000:00:14.0-1, super speed : USB Audio

Playback:
  Status: Running
    Interface = 1
    Altset = 3
    Packet Size = 4096
    Momentary freq = 48000 Hz (0x6.0000)
  Interface 1
    Altset 1
    Format: S32_LE
    Channels: 54
    Endpoint: 0x02 (2 OUT) (ASYNC)
    Rates: 44100, 48000, 88200, 96000, 176400, 192000
    Data packet interval: 125 us
    Bits: 24
    Sync Endpoint: 0x82 (2 IN)
    Sync EP Interface: 1
    Sync EP Altset: 1
    Implicit Feedback Mode: No
  Interface 1
    Altset 2
    Format: S32_LE
    Channels: 102
    Endpoint: 0x02 (2 OUT) (ASYNC)
    Rates: 44100, 48000, 88200, 96000, 176400, 192000
    Data packet interval: 125 us
    Bits: 24
    Sync Endpoint: 0x82 (2 IN)
    Sync EP Interface: 1
    Sync EP Altset: 2
    Implicit Feedback Mode: No
  Interface 1
    Altset 3
    Format: S32_LE
    Channels: 198
    Endpoint: 0x02 (2 OUT) (ASYNC)
    Rates: 44100, 48000, 88200, 96000, 176400, 192000
    Data packet interval: 125 us
    Bits: 24
    Sync Endpoint: 0x82 (2 IN)
    Sync EP Interface: 1
    Sync EP Altset: 3
    Implicit Feedback Mode: No

Capture:
  Status: Running
    Interface = 2
    Altset = 3
    Packet Size = 4096
    Momentary freq = 48000 Hz (0x6.0000)
  Interface 2
    Altset 1
    Format: S32_LE
    Channels: 52
    Endpoint: 0x81 (1 IN) (ASYNC)
    Rates: 44100, 48000, 88200, 96000, 176400, 192000
    Data packet interval: 125 us
    Bits: 24
  Interface 2
    Altset 2
    Format: S32_LE
    Channels: 100
    Endpoint: 0x81 (1 IN) (ASYNC)
    Rates: 44100, 48000, 88200, 96000, 176400, 192000
    Data packet interval: 125 us
    Bits: 24
  Interface 2
    Altset 3
    Format: S32_LE
    Channels: 196
    Endpoint: 0x81 (1 IN) (ASYNC)
    Rates: 44100, 48000, 88200, 96000, 176400, 192000
    Data packet interval: 125 us
    Bits: 24

The above looks okay to me. The device switches properly to altset 3 but the sound is still distorted.

In this mode, I recorded a 440 Hz test signal routed from my digital console to MADI3 (coaxial) input 1, which is input 129 on the Madiface. The console synced properly, indicated by steady sync lights on both the console and the Madiface.

The recorded sine looked and sounded mostly clean with some weird overtones at ~9.1 and 10.2 kHz and two more about 10k higher. But what puzzled me the most, was that the fundamental was exactly 100 Hz higher at 540 Hz. Now that I think of it, the garbled playback sound is also slightly higher than the set frequency.

This has to be a clue, hasn't it?

EDIT: In the meantime I opened an issue at the alsa-lib Github repo. Let's hope I'm in the right place...

Re: Madiface XT II Channel Count in CC mode

Here's a link to the 6.19 kernel patch that fixed the usb3 functionality on my ufx3 https://lore.kernel.org/linux-sound/202 … u.com/T/#u
There's this in the discussion within.

"Note that there is a small gotcha here: Dylan's patch and the original
code, as well as usb_submit_urb(), didn't take wBytesPerInterval into
account, while usb_endpoint_max_periodic_payload() and xhci_hcd do.

Odd SuperSpeed endpoints like those below will now be considered to
have 512B/1536B capacity, not 1KB/2KB. Whether any such UAC devices
exist (mine is UVC) I don't know. My only SuperSpeed UAC device uses
one packet per interval and wMaxPacketSize == wBytesPerInterval."

I'm nowhere near knowledgeable enough to say if that's relevant but others here may be able to tell if this patch may just work for the ufx3 and not the madiface.

Re: Madiface XT II Channel Count in CC mode

I can't tell from the link if that fix eventually made it into the kernel, but if it did, the patch obviously isn't helping with the Madiface as I'm on a much newer kernel.