snd_soc_usb_...ffload_route(9)

📦 version 7.3.1, in nixpkgs unstable

💖 NAME 💖

snd_soc_usb_update_offload_route — bestie, this is the one that finds your active USB offload path ✨

Oh and hiii, welcome to the Kernel API Manual, section 9 — yes we're in the big-league kernel docs today, put your hair up 🎀

🌸 SYNOPSIS 🌸

int snd_soc_usb_update_offload_route (struct device *dev , int card ,
int pcm , int direction , enum snd_soc_usb_kctl path , long *route );

okay so it returns an int, it takes a whole little friend group of args, and it's giving "I know where the audio is going" energy 💅

🦋 ARGUMENTS 🦋

  • dev — the USB device you're asking about, aka where we go to get the offload status 👀
  • card — the USB card index, literally just the card's number 🎀
  • pcm — the USB PCM device index, the pcm's number, no cap 🎧
  • direction — playback or capture direction, pick your fighter 🔊
  • path — a pcm or card index (that's the type enum snd_soc_usb_kctl, iykyk) 🌈
  • route — pointer to the route output array, this is where the answer lands 🫶

✨ DESCRIPTION ✨

So what does it do? It fetches the current status for the USB SND card index and PCM device index you specified. Iconic. Obsessed. 💜

The route argument should be an array of integers being used for a kcontrol output 📋 — and listen close, because the layout matters, bestie:

  • the first element should have the selected card index
  • the second element should have the selected pcm device index

That's the whole vibe check. Two slots, two jobs, no drama 🧚

🔥 SEE ALSO 🔥

Kernel file ./sound/soc/soc-usb.c and its whole squad:

💀 friendly reminder from your girl: route is a pointer to an array of integers, so it better have room for the card index at [0] and the pcm index at [1]. Don't come crying to me when you write past it. 🙈

okay that's the page!! this came out of ./sound/soc, dated October 2026, and it's filed under snd_soc_usb_...ffload_route(9) in the Kernel API Manual 🌟 mwah, go read the rest of the squad, ily, bye!! 💖🎀🦋

📦 where this page comes from