OH MY FUCKING GOD.
Pictured: Apple's M2 MacBook Air 13" speaker response (measured with a mic), and the response you get when you zero out every 128th sample of a sine sweep.
They have a stupid off-by-one bug in the middle of their bass enhancer AND NOBODY NOTICED NOR FIXED IT IN OVER A YEAR.
So instead of this (for a 128-sample block size):
for (int sample = 0; sample <= 127; sample++)
// process sample
They did this:
for (int sample = 0; sample < 127; sample++)
// process sample
Legendary audio engineering there Apple.
We can now, very confidently say the audio quality of Asahi Linux will be better than Apple's. Because we don't have blatant, in your face off-by-one bugs in our DSP and we actually check the output to make sure it's good
FFS, and people praise them for audio quality. I get it, the bar is so low it's buried underground for just about every other laptop, but come on...
Edit: replaced gif with video because Mastodon is choking on the animation duration...
Edit 2: Update below; I can repro this across a large range of versions on this machine but none of the other models I've tried so far. It is definitely a bug, very very obvious to the ear, and seems unique to this machine model.
Edit 3: Still there in Sonoma, this is a current bug.
Tested 12.4 and 13.5 on M2 MBA, sounds just as bad, so this has been going on for a *long* time now.
M1 MBA does not have this problem, nor does M1 MBP 16". This might be an M2 MBA specific problem. It is very, *very* obvious if you just play a 300Hz sine with any random frequency generator website and crank the volume up.
Upgrading to Sonoma now, but I doubt they fixed it... it seems this has *always* been broken on at least the M2 13" MBA.
Edit: Still there in Sonoma.
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.
@marcan It's a great reminder that a few people hammering away at this stuff can make really good products, for lack of a better word.