I’ve now received two reports about Capo not playing audio for some projects in macOS Sonoma. Users have reported either “clicking sounds”, or silence in place of the music they expect to hear. Unfortunately, I am unable to reproduce this problem on my M1 Max MacBook Pro.
Do any of you have an Intel Mac that’s running macOS Sonoma? If so, do you notice any issues with audio playback? I’m trying to identify whether there’s some kind of a pattern that leads to these problems.
I’m still researching this actively, and trying to get my hands on Intel hardware for testing.
In the meantime, I’ve found some interesting information that could beare not related to the issues customers are experiencing:
Intel Macs are designed in such a way that built-in audio hardware is basically just another USB device. So if there are severe issues with USB audio, that would explain why Intel macs are the ones having trouble.
If I had to guess, someone must have messed with the device driver for the USB controller that’s found in the Intel Macs, and it caused havoc downstream. I’m sure it’ll get fixed soon, because USB audio is still a very big deal on macOS.
Update: I made an emergency purchase of a second-hand, 16" MacBook Pro (2019) that’s powered by an 8-core i9 CPU. I have now reproduced the audio issue in-house, and I am actively looking for a workaround.
The actual problem is extremely weird, and I am currently unsure how to properly fix this.
From the user’s perspective, certain .m4a audio files refuse to play any sound in Capo. I have yet to identify what the key difference is between those files. They have the same sample rate, are all stereo, and have similar bit rates. Also, they all are encoded with the AAC codec.[1]
Deep under the hood, something is causing the audio data to get corrupted. “Problematic” audio files still appear to have correctly-decoded audio samples. If I bypass the processing of my audio slowing engine, the corruption goes away.
Seems like the audio slowing engine is to blame, right? Not necessarily! If that was the problem, then all audio playback should be broken, and not just the ones that get decoded from certain .m4a audio files. That’s because the slowing engine knows nothing about the audio file—it’s already been decoded elsewhere, and the slowing engine only sees a bunch of numbers!
Unfortunately, there are a lot of places where this issue could be hiding, so I have my work cut out for me.
I’ll post updates here as I make progress on this.
Fun fact: .m4a audio files can contain audio data compressed using AAC or ALAC audio codecs, and potentially others. ↩︎
I’m popping in again to provide another update on my progress.
I’ve narrowed down where the problem is coming from. Something deep in the system is causing the Intel CPU’s floating point unit to misbehave. This kind of thing can happen when someone’s math code didn’t clean up after itself properly. I’m guessing that the math in question is related to the decoding of certain M4A audio files.
I have a possible workaround for this issue, but it’s a dangerous one: it could create additional problems, and there’s a chance that the same bug will pop its head up somewhere else.
So now I need to try and write some code that pokes around and makes this problem happen on demand, and that’ll either (a) push Apple to fix the underlying bug, or (b) surface a more robust workaround.
Sorry this is taking so long, but such is the nature of nasty bugs!
This is caused by a system-level bug that is triggered when JPEG images are decoded. So certain m4a audio files is actually certain m4a audio files with album artwork.
I’m working on producing a workaround for this, and I am also trying to document the journey that got me to that conclusion. It was a wild ride, to say the least.
Stay tuned for an update regarding a bugfix release.
Capo 4.3.7 contains a workaround for the system bug that caused Capo to lose its audio playback on Intel machines. The update should appear on the Mac App Store shortly.
Please let me know if any of you encounter any further trouble.