Return to

Rodecaster Pro - Bad audio out [Solved]

Recently switched back to full time Linux from Windows and the only issue that i’m having is the usb audio output for the Rodecaster Pro is garbled. See following link for a recording of the output.

EDIT: SOLUTION - Use the rodecaster with a non-amd chipset usb port. An off the shelf pcie usb card worked for me.

I’m currently running manjaro on the 5.12 kernel so it is after the alsa patches for the rodecaster to set it to 48000 hz. Input audio sounds fine from the rodecaster with the default settings for pulseaudio in manjaro. I’ve tried running through all of the troubleshooting steps in the audio quality section of the arch troubleshooting page here. I’ve also tried running jack and it has the same issue.

Looking for any further tips on troubleshooting the issue.

here’s the pacmd list-sinks output:
index: 0
name: <alsa_output.usb-RODE_Microphones_RODECaster_Pro_00000000001A-01.iec958-stereo>
driver: <module-alsa-card.c>
state: IDLE
suspend cause: (none)
priority: 9048
volume: front-left: 65536 / 100% / 0.00 dB, front-right: 65536 / 100% / 0.00 dB
balance 0.00
base volume: 65536 / 100% / 0.00 dB
volume steps: 65537
muted: no
current latency: 100.11 ms
max request: 37 KiB
max rewind: 37 KiB
monitor source: 0
sample spec: s32le 2ch 48000Hz
channel map: front-left,front-right
used by: 0
linked by: 0
fixed latency: 99.94 ms
card: 0 <alsa_card.usb-RODE_Microphones_RODECaster_Pro_00000000001A-01>
module: 6
alsa.resolution_bits = “32”
device.api = “alsa”
device.class = “sound”
alsa.class = “generic”
alsa.subclass = “generic-mix” = “USB Audio” = “USB Audio”
alsa.subdevice = “0”
alsa.subdevice_name = “subdevice #0
alsa.device = “0”
alsa.card = “3”
alsa.card_name = “RODECaster Pro”
alsa.long_card_name = “RODE Microphones RODECaster Pro at usb-0000:0b:00.3-4.4.3, high speed”
alsa.driver_name = “snd_usb_audio”
device.bus_path = “pci-0000:0b:00.3-usb-0:4.4.3:1.1”
sysfs.path = “/devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:0b:00.3/usb3/3-4/3-4.4/3-4.4.3/3-4.4.3:1.1/sound/card3” = “usb-RODE_Microphones_RODECaster_Pro_00000000001A-01”
device.bus = “usb” = “19f7” = “RODE Microphones” = “0011” = “RODECaster Pro”
device.serial = “RODE_Microphones_RODECaster_Pro_00000000001A”
device.string = “iec958:3”
device.buffering.buffer_size = “38376”
device.buffering.fragment_size = “9592”
device.access_mode = “mmap” = “iec958-stereo”
device.profile.description = “Digital Stereo (IEC958)”
device.description = “RODECaster Pro Digital Stereo (IEC958)”
module-udev-detect.discovered = “1”
device.icon_name = “audio-card-usb”
iec958-stereo-output: Digital Output (S/PDIF) (priority 0, latency offset 0 usec, available: unknown)

	active port: <iec958-stereo-output>

That might be your problem. Try setting it to s16le or s24le

1 Like

I am not familiar with the audio happenings on Linux. Just happy I got both my soundcards to work.

Try running 24 bit and a 1024 sample buffer size (audio buffer).

1 Like

So doing some research, it looks like most 24 bit cards use 24 bits packed into 32 which I think is why pulse is saying 32. That being said, i’ve tried setting the default-sample-format in /etc/pulse/daemon.conf to s24le, float24le, and float32le, but these settings seem not to change anything in pacmd list-sinks

Edit: I’ve also tried forcing 16 bit when using jack without any success, i also did read somewhere that the rodecaster pro only supports 24 bit

Yeah, luckily the input is working and is the most important part with the rodecaster, i have another sound card that works for output, just less convenient to use both (and the rodecaster has better amps)

tried switching to pipewire, still have the same issue, pw-dump output:

   "id": 42,
   "type": "PipeWire:Interface:Node",
   "version": 3,
   "permissions": [ "r", "w", "x", "m" ],
   "info": {
     "max-input-ports": 64,
     "max-output-ports": 0,
     "change-mask": [ "input-ports", "output-ports", "state", "props", "params" ],
     "n-input-ports": 2,
     "n-output-ports": 2,
     "state": "suspended",
     "error": null,
     "props": {
       "object.path": "alsa:pcm:3:iec958:3:playback",
       "api.alsa.path": "iec958:3",
       "api.alsa.pcm.card": 3,
       "": "playback",
       "audio.channels": 2,
       "audio.position": "FL,FR",
       "device.routes": 1,
       "alsa.resolution_bits": 32,
       "device.api": "alsa",
       "device.class": "sound",
       "alsa.class": "generic",
       "alsa.subclass": "generic-mix",
       "": "USB Audio",
       "": "USB Audio",
       "alsa.subdevice": 0,
       "alsa.subdevice_name": "subdevice #0",
       "alsa.device": 0,
       "alsa.card": 3,
       "alsa.card_name": "RODECaster Pro",
       "alsa.long_card_name": "RODE Microphones RODECaster Pro at usb-0000:0b:00.3-4.4.3, high speed",
       "alsa.driver_name": "snd_usb_audio",
       "": "iec958-stereo",
       "device.profile.description": "Digital Stereo (IEC958)",
       "card.profile.device": 5,
       "": 37,
       "": "api.alsa.pcm.sink",
       "priority.driver": 816,
       "priority.session": 816,
       "media.class": "Audio/Sink",
       "node.nick": "RODECaster Pro",
       "": "alsa_output.usb-RODE_Microphones_RODECaster_Pro_00000000001A-01.iec958-stereo",
       "node.description": "RODECaster Pro Digital Stereo (IEC958)",
       "node.pause-on-idle": false,
       "": 18,
       "": 30,
       "node.driver": true,
       "factory.mode": "merge",
       "audio.adapt.follower": 0,
       "": "audioconvert/libspa-audioconvert",
       "": 42,
       "node.max-latency": "32768/48000"
     "params": {
       "EnumFormat": [
           "mediaType": "audio",
           "mediaSubtype": "raw",
           "format": "S32LE",
           "rate": 48000,
           "channels": 2,
           "position": [ "FL", "FR" ]
       "PropInfo": [
           "id": "volume",
           "name": "Volume",
           "type": { "default": 1.000000, "min": 0.000000, "max": 10.000000 }
           "id": "mute",
           "name": "Mute",
           "type": {
             "default": false,
             "alt1": false,
             "alt2": true
           "id": "channelVolumes",
           "name": "Channel Volumes",
           "type": { "default": 1.000000, "min": 0.000000, "max": 10.000000 },
           "container": "Array"
           "id": "channelMap",
           "name": "Channel Map",
           "type": 0,
           "container": "Array"
           "id": "device",
           "name": "The ALSA device",
           "type": "iec958:3"
           "id": "deviceName",
           "name": "The ALSA device name",
           "type": ""
           "id": "cardName",
           "name": "The ALSA card name",
           "type": ""
           "id": "minLatency",
           "name": "The minimum latency",
           "type": { "default": 16, "min": 1, "max": 2147483647 }
           "id": "maxLatency",
           "name": "The maximum latency",
           "type": { "default": 8192, "min": 1, "max": 2147483647 }
           "id": "id-01000000",
           "name": "Use the driver channelmap",
           "type": false
       "Props": [
           "volume": 1.000000,
           "mute": false,
           "channelVolumes": [ 0.399992, 0.399992 ],
           "channelMap": [ "FL", "FR" ],
           "monitorMute": false,
           "monitorVolumes": [ 0.399992, 0.399992 ]
           "device": "iec958:3",
           "deviceName": "",
           "cardName": "",
           "minLatency": 16,
           "maxLatency": 8192,
           "id-01000000": false
       "Format": [ ],
       "EnumPortConfig": [
           "direction": "Input",
           "mode": "dsp"
           "direction": "Output",
           "mode": "dsp"
           "direction": "Input",
           "mode": "convert"
           "direction": "Output",
           "mode": "convert"
       "PortConfig": [
           "direction": "Input",
           "mode": "dsp"
           "direction": "Output",
           "mode": "convert"

Edit: corrected pw-dump output


Were you able to solve that issue? I’m fighting with same thing and can’t really find any solution anywhere.

Unfortunately no I haven’t found a solution. Sorry for not getting back sooner I just saw your comment as i was researching the issue again and my own post was the third result… :sweat_smile: If I do find an answer I’ll have to make sure to update this thread since it’s such a high result.

At this point i’m pretty sure it’s some kind of interaction between amd cpus/chipset (possibly ryzen 3000?) and the rodecaster. I’m basing this off of a couple things.

1.) If I boot up an ubuntu live usb on an intel machine the rodecaster works fine whereas on both of my amd machines it does not

2.) it could still be an interaction between the rodecaster and the graphics card as my intel machine has an amd gpu and both of my amd machines have an nvidia gpu, however I saw a thread where a guy said his rodecaster wasn’t working even when he tried pulling out his gpu

so my best guess is there’s some kind of issue in the chipset kernel usb modules that prevents the rodecaster from working. There’s a chance that using a usb port that’s not using the amd chipset could get the rodecaster working but unfortunately I don’t have any other chipset on my machines to try that. I mighht pick up a pci usb controller to try it out though

@nightf somewhat good news, the rodecaster pro works perfectly with a pcie usb card. it is unfortunately a hardware solution but assuming you’re on a desktop it’s a reasonably cheap one.

SOLUTION: Use the rodecaster with a non-amd chipset usb port.

Do you have a BIOS update available? AMD finally fixes USB bugs with Ryzen CPUs – but patch won’t roll out for a while yet | TechRadar

Hey, thanks for reaching back and lettink me know. So as I’m in the same boat, with only amd controller on my MOBO, so will need to get some PCIe card with USB ports as well, but at least it will work! So thanks angain.

@NZSNIPER I tried upgrading BIOS to version with AMD AM4 AGESA V2 PI Patch C - and it did not solve the issue, but thanks for your article :slight_smile:

Yeah, I also tried updating my bios before trying a pcie card because I knew they had fixed some usb issues but unfortunately that didn’t work for me either. I think the issue is actually in the linux kernel modules as it works in windows (or at least the kernel modules don’t have some crazy workaround for some kind of hardware/firmware level issue).