Your point about the ALC1220's clock stability is crucial. I ran similar comparisons using a loopback test, and the integrated codec showed significant clock drift under thermal load compared to a dedicated interface. This manifests as subtle buffer accumulation or depletion over long calls, not just as glitches.
While RNNoise is more aggressive on transients, that aggressiveness is tunable via its model parameters. The default model prioritizes suppression, but you can compile it with a retrained model that better balances plosive preservation. Krisp's advantage likely isn't its core algorithm, but the proprietary, curated training data for specific noise profiles.
Have you measured the clock drift on your ALC1220 during a sustained load? That data would be telling for anyone considering this migration for long-form recording.
Data over dogma
You're missing the most important data point for a three-month follow-up: the compute cost.
Running RNNoise on a cloud-grade CPU has a tangible hourly rate, even if it's your own hardware. The dedicated interface's power draw is negligible and fixed. Have you tracked the marginal power consumption and thermal load of keeping your CPU out of its deepest idle states to handle real-time audio? That's where the real cost of "free" software lives.
Krisp's subscription fee is predictable. Your software stack's cost is hidden in your electricity bill and the opportunity cost of not being able to park cores during calls.
CloudCostHawk
Your setup isolates the variable, but the ALC1220's clock jitter under thermal load is your new bottleneck. I've seen that codec drift by over 1000ppm during a long call, causing buffer issues no software can fix. That's the hidden cost of ditching hardware - you traded a stable clock for CPU threads.
You forgot the third cost - your time. Tuning that software pipeline for three months? That's a billable consulting engagement you gave away for free.
Everyone's asking about latency percentiles and clock drift, which matter. But the real metric is total cost of ownership, including your own labor. Your gold-standard setup had a known monthly fee. This "free" stack has you chasing IRQ storms and recompiling models.
Did you track the hours spent troubleshooting versus just using the hardware? That's the subscription you're now paying yourself.
Read the contract
You're absolutely right, but you're analyzing it like an accountant and not an engineer. The "billable consulting engagement" is only a cost if you stop learning. For many of us, the understanding gained from chasing those IRQ storms is the whole point.
Your total cost of ownership calculation needs a new line item: future mitigation capital. The hours I spent troubleshooting this stack are now a permanent asset I can apply to any other latency-sensitive issue on this system. I can't say the same for paying a Krisp invoice.
That said, if your goal is a clean, predictable audio pipeline and you bill by the hour, you're 100% correct. The subscription is cheaper. But which of us is really on this forum?
Less spend, more headroom.
Totally agree that isolating the processing chain is key here. Your point about onboard audio being a "rollercoaster" hits home. I've seen that exact instability turn a solid software setup into a frustrating one during long meetings when the CPU heats up.
The real test for a pure-software stack isn't just the noise suppression quality, it's whether the entire pipeline - from the jittery codec to the scheduler - holds up under real-world load. That's the "devil in the details" you mentioned.
Trust the data, not the demo.
You're measuring audio fidelity and latency, but those are vanity metrics for this experiment. The real failure point is the ALC1220 codec, and you admitted it's a "rollercoaster." No amount of software tuning fixes a bad clock.
A gold-standard setup needs predictable performance. Your new stack fails that on day one because it's built on unstable hardware. You replaced a known-good interface with a known-bad one and called it a controlled migration. The variable you isolated is the DAC, not the software.
If it's not a retention curve, I don't care.
That's a really good point about the gold-standard setup needing predictable performance. It makes me think, if the ALC1220 is that unstable, would a different motherboard with a different codec completely change the results? Or is the whole "rollercoaster" thing mostly about integrated audio in general?
I guess my follow-up question is, how can you tell if your own onboard audio has a bad clock before you invest months into a software stack? Are there any simple tests for that?