The thing about this bug is that it makes me confident that we can do better, not just in terms of not making this mistake.

When you're doing DIY DSP like this, it's always hard to objectively be confident that you can do a decent job vs. a company with many more employees and resources (e.g. to run high quality tests, user studies, etc.); after all, we're not psychoacoustics experts here, there could be some real "magic sauce" to Apple's DSP that we can't reproduce.

Anyone can make this kind of mistake while writing DSP code, but the fact that nobody caught this before launch, never mind in over a year in the wild, makes it evident that Apple's audio engineering team is, at least on some level, incompetent (or incompetently run; I'm not blaming the employees here, but rather the organization). This is both obvious to the ear side by side with other machines, and obvious in a sine sweep frequency response test, which is the most basic test you can run end-to-end on a completed audio system to ensure it is performing properly. So they didn't even run that. Or they ran it, and didn't notice this. Which is nuts.

So now I feel a lot more confident that the less over-the-top DSP we're aiming for in Asahi is going to be competitive, because clearly Apple's audio team aren't audio geniuses with dark knowledge we don't have. At least on some level they're flailing around with open-coded time domain DSP and aren't running any serious analysis on the result, because anything would've caught this, especially in contrast to it not happening on other machines.