Blog
Linux Kernel Driver Maintenance for Raspberry Pi Audio Products: Let us help you
If your audio product is built around a Raspberry Pi, you almost certainly have a custom kernel driver and device-tree overlay sitting underneath it — for the DAC, the ADC, the clock setup, the GPIO control logic. That driver is what makes the hardware visible to ALSA and to every piece of audio software running on top.
Once the product ships, that driver is yours to live with. And the kernel underneath it does not sit still.
The trap of “we’ll just patch it once”
Most Raspberry Pi audio projects start the same way: pick a similar driver from the kernel tree, patch it for the new DAC or ADC, build it against the current Raspberry Pi kernel, ship.
It works. The first batch goes out. Customers are happy. The hardware team moves on.
Then the kernel keeps moving. The Raspberry Pi kernel is rebased on new mainline releases regularly. ASoC (the kernel audio subsystem) refactors helpers between versions. Sample-rate constraint APIs change. Probe-time GPIO handling gets tightened. Suddenly that one-time patch doesn’t apply cleanly anymore — and the failure mode isn’t always loud. A missing 384 kHz sample rate, a wrong channel order at startup, a probe that races with I²C initialisation. The first time you notice is when you sit down to ship the next firmware update or OS image — and the driver no longer compiles, or it compiles and silently misbehaves.
Bug fixes are work. Security fixes are not optional.
Two categories that don’t go away:
Compatibility and bug fixes. New Raspberry Pi kernel release, ALSA helper renamed, a clock provider moves to a new API. None of these are dramatic individually, but each one needs someone who knows the driver and the audio subsystem to look at it, fix it, and verify it on real hardware. Multiplied over the lifetime of a product, that’s a steady stream of low-volume kernel work.
Security fixes. When a CVE lands in a subsystem that touches your driver — DMA, I²C, USB audio, sound core — fixes have to flow through to the kernels your customers run, and your driver has to keep working on top of those fixes. For products in regulated environments (medical, industrial, broadcast, anything with mandatory support windows), “we don’t update the kernel” is not a position the regulator will accept.
“Freeze the OS image” is not a strategy
The common workaround: ship a fixed Raspberry Pi OS image and never touch it again.
The problem is that “frozen” only describes the customer side. The end customer typically can’t — and shouldn’t be expected to — touch the kernel themselves. But you still have to ship bug fixes and updates. Field-discovered bugs, security CVEs in subsystems the device relies on, support for new peripherals or accessories, regulatory patches: each of those forces a new image, and each new image rides on a kernel that has moved since the last one. The driver has to come along.
So the choice isn’t “maintain or freeze.” It’s “maintain, or eventually ship a broken update to your customers.”
We’ve been doing this since 2013
At HiFiBerry we’ve maintained our own audio driver stack in the official Raspberry Pi kernel sources since 2013 — across many boards, sample-rate configurations, and successive Pi generations. We know how the Pi audio path is wired, how ASoC has evolved, and where the tripwires are when the kernel rebases.
If you’re shipping a Raspberry Pi based audio product and the driver maintenance is becoming a distraction from the hardware work you actually want to do, we can help. Specifically:
- Custom audio driver and device-tree overlay development for your DAC / ADC / mixed-signal hardware.
- Integration into the official Raspberry Pi kernel sources, so the driver ships with stock Raspberry Pi OS — no out-of-tree modules, no install scripts at the customer end.
- Ongoing maintenance — bug fixes, kernel-version compatibility, security follow-through — for the supported lifetime of your product.
Not a Raspberry Pi based product?
We’ve also done this for other SBC platforms in the past — Allwinner, Rockchip, NXP and similar. Honest framing: it’s usually more effort than on the Pi, because most SBC vendors put far less ongoing work into kernel maintenance than the Raspberry Pi Foundation does. Their kernels are often forks frozen years ago, with limited upstream visibility and unpredictable rebase paths. None of that makes it impossible — it just means the scoping conversation is different. Talk to us about your specific platform and we’ll look at what’s realistic.
The hardware is your IP. The kernel work doesn’t have to be your problem.
If this resonates with where your team is right now: support@hifiberry.com.
May 12, 2026
