I haven't listened to this podcast yet so I don't know if this comes up, but a particularly scary part of running a custom OS on Apple Silicon machines is that the internal speakers temperature is regulated in software. The Asahi devs have had to painstakingly reverse engineer and reimplement the safety DSP that macOS uses on each device, and add some safety margin, because if they get it wrong they could literally destroy the speakers (and IIRC at least one of their own MacBooks did have its speakers sacrificed along the way).
I wonder if there will be a similar issue with the displays when Asahi gets around to supporting HDR on machines equipped with FALD mini-LED backlights (or XDR, as Apple calls it). HDR displays usually regulate their brightness to keep the panel from getting too hot, and if Apple does that in software too then Asahi will need to replicate it.
As someone who builds speakers commercially, there aren't any devices that will actually monitor a speaker's temperature. I think what you mean is perhaps, wattage? The speaker's temperature arises from the coil, which is what moves to produce sound. In large speakers, I've seen manufacturers attach some sort of sensors pointing at the moving coil to produce an estimate, but for the speakers used in the Macbooks, they are so thin that this would be a near impossible feat. Maybe Apple uses an estimation from the DSP based on the watts supplied vs time. But, certainly, you cannot attach any sort of device to the coil without making it distort or non-functional.
I know that Apple like to supply the speakers with slightly more power (Watts) than they can deal with to get them loud, but I haven't seen nor heard of this temperature monitoring so far. I couldn't find anything related to it either. Please share citations, if you have.
You're probably right. I looked at Neumann ("Independent soft clip, peak and thermo limiters for woofer and tweeter; Woofer excursion limiter; thermo limiter for the electronics and amplifiers") and Genelec (https://www.genelec.com/key-technologies/protection-circuitr...) for info - as they're the reference in the monitoring world - and my guess is that it's implemented like Apple, via some simulation function from time-integrated wattage and frequency to bool (limit on/off).
Apple isn't the first to use advanced limiters to get the most of loudspeakers, if I remember well, this trick is what allowed Devialet to make the Phantom what it is.
Which is why loudspeaker measurements should _always_ include something like this: http://0x0.st/XG1y.png
I don't know what apple is doing, but in theory, it should be possible to measure ohmic resistance of the coil, and infer temperature via PTC coefficient of coil material. The effect isn't very big at temperature differences you could tolerate in a loudspeaker coil though (~0,5%/K).
The fact that speaker temperature even needs to be considered is something that boggles the mind. I can't find any other references elsewhere on the Internet. Are you sure it's not DC blocking that they've cheaped out on somehow? It somewhat reminds me of this: https://news.ycombinator.com/item?id=7205759
They do it because it lets them drive the speakers much louder than they could do safely with a simple power limiter. Apparently there are amplifier chips which can do that smart regulation internally but Apple decided to do it in software for whatever reason. Maybe they can squeeze out more sound quality with a more complex DSP that way, I doubt it's cost-cutting given their margins.
Certainly I can see the appeal of implementing control in the silicon I own rather than buying a vendor's chip and having to deal with their supply chain, their sales team, their space claim on my board, etc.
It's probably a combo of cost-cutting and control. If you use a hardware chip, the chip itself only costs cents, but space is at a premium, and there assembly costs and reduced flexibility (you have to lock in your design well in advance).
Cost-cutting, control, malicious compliance, and more importantly, plausible deniability. Apple has been caught sabotaging third-party repair multiple times and this sort of design is totally in line with that strategy. Making the design overly complex and fragile (and spending extra $$$ in the process), just to make it harder to correctly use, seems to be a common theme. They will of course come up with plausible arguments why their design is "better", but in reality it's only better for them.
> Apparently there are amplifier chips which can do that smart regulation internally but Apple decided to do it in software for whatever reason.
> Apple has been caught sabotaging third-party repair multiple times and this sort of design is totally in line with that strategy.
Using fewer specialized hardware chips to dynamically regulate speaker temperatures and implementing it in software seems like it would be more repair-friendly, not less. Unless you meant this in some more general sense that doesn't include repair, per se?
> Apple has been caught sabotaging third-party repair multiple times and this sort of design is totally in line with that strategy. Making the design overly complex and fragile (and spending extra $$$ in the process), just to make it harder to correctly use, seems to be a common theme.
This, and the nannying nature of their OS is why I could never have a mac as a primary machine. I'm always slightly mind-boggled at the amount of technical people that do. But then I guess many just live in an IDE which works fine.
I've worked with PC laptop manufacturers before, and they do exactly the same thing. In every case, it's either "how can we take really cheap speakers with limited placement options and make them sound decent, to save costs", or "how can we take slightly better speakers and slightly better placement options and make them sound like surround sound so our audio can be a selling point".
It doesn't require malice or conspiracy to wind up with a closed proprietary design that makes up for cheap flawed hardware with software workarounds. It's the default if you don't have the opposite as an key value and make a deliberate effort to achieve it.
Yeah - the same thing has been happening for well over a decade with phone cameras. I bought a fancy full frame dslr camera recently and the image quality is incredible. But the sensor on my camera is 30x larger than my phone’s sensor (or something like that). And good lenses are massive - my arms get a workout from shooting.
It really puts into relief how weird it is that we get such good quality out of phone cameras. They’re almost as much generative AI images as they are actual photos.
Of all of those reasons, malicious compliance and plausible deniability seem the least likely to me. With and from what, exactly?
I get being upset at Apple for e.g. 30% take on in-app purchases. But what exactly would they be trying to do by making it complex to control their speakers?
But what exactly would they be trying to do by making it complex to control their speakers?
Making it harder for alternative OSes to use their hardware without accidentally damaging it, further cementing macOS' position as the only OS to be trusted.
It's similar to their war against third-party repair shops by deliberately making it difficult to replace parts, even with genuine ones --- see my second link about the iPhone 12 camera.
This is the automotive equivalent of adding sensors and ECU firmware that detects if the engine is using the manufacturer's proprietary oil, and subtly changing the parameters to decrease power and fuel economy, increase emissions, and/or shorten the life of the engine if it isn't. Then blaming third-party repair shops when customers complain.
> Making it harder for alternative OSes to use their hardware without accidentally damaging it, further cementing macOS' position as the only OS to be trusted.
If apple wanted to kill asahi linux, they wouldn't have had to lift a finger. Its the opposite - Apple engineers have needed to do several small things to keep the door open to easily run 3rd party operating systems on their computers. Remember, a modern mac has essentially identical hardware as an ipad. Apple has locked down the entire boot process and uses digital signatures all through the boot chain. They actively changed how macs boot to make sure things like asahi linux can run on their computers at all.
I don't think they deserve special praise for that. But it does make it a stretch to claim their speakers were intentionally designed hurt linux-on-mac. If they wanted to stop asahi linux, they had plenty of much easier, much more effective ways to do so.
Sounds like "be glad they gave you some bones from the table" instead, you know, the company providing the actual proper means for users to reliably run whatever on the hardware they bought, not just the manufacturers blessed OS.
Sometimes I wonder if it really makes sense to spend so much time to do the work Apple should have done in the first place & with no guarantee it will even work after a firmware upgrade or on the next model.
Spending the same effort on more open platforms or open hardware efforts might be wiser in the long term.
On one hand I agree with you, on the other hand I'm happy they are taking the effort to do this because it will reduce e-waste. When those MacBooks no longer receive updates, they can get a second life thanks to this work.
Yes, I did say in my comment that I don’t think they deserve special praise for making a computer a computer. I have complicated feelings about it all too. On one hand, I wish my Apple devices were more open: I think the App Store tax is anticompetitive abuse of a monopoly. I have an expectation of actually owning the things I buy, and I don’t feel that way about the software ecosystem on my iPhone.
On the other hand, I adore the security and cross-application sandboxing that iOS brings. I wish Linux had more ways to sandbox applications from one another - since it’s clear that “trust all computer programs” is an insanely idiotic policy in 2024. And “implicitly trust all code” is de facto how Linux, npm, cargo, etc all run today.
My comment was in response to the idea that the speakers are maliciously designed to hurt asahi Linux, which just seems obviously wrong given how much power Apple has over their devices. They could completely kill asahi Linux with a flick of the wrist if they ever want to. There’s no way that’s the reason for their complex speaker setup.
My comment was in response to the idea that the speakers are maliciously designed to hurt asahi Linux, which just seems obviously wrong given how much power Apple has over their devices. They could completely kill asahi Linux with a flick of the wrist if they ever want to. There’s no way that’s the reason for their complex speaker setup.
If they killed off asahi Linux, they would face far more backlash than if they just made it harder for them (with ostensible reasons why), while keeping it strictly worse than macOS.
Apple has a very long history of implementing hardware drivers "in software". Steve Wozniak famously did this for a floppy disk drive for one of Apple's early computers.
I think it's just a different, integrated, approach to hardware a software development. If you're doing things custom anyway, then why add an extra chip?
Because:
1. Software is more likely to fail at protection with worse consequences when it does (fire, damaged goods, warranty claims). Not just now, but also the future updates.
2. It eats away at the resources that are intended for the user. In other words: it makes the machine slightly slower for the user, for no good reason to the user.
3. You can do things that are impossible in laptop OS software. It gives redundancy, even if the OS freezes you can still make sure the speaker doesn't overheat. If it's implemented in a seperate chip. Also there is real time ability, etc.
4. It makes the OS and drivers much much simpler, which is important if you want to support other OSes on the same laptop.
Advantages, for Apple, to do it in software:
1. Software upgrade is easier and cheaper (assuming they never ever fail).
2. Cheaper.
3. You can keep competing OS'es off of your hardware, because it's too hard to write drivers for your secret sauce closed source drivers that include functionality that is "preventing parts from frying themselves".
The control loop is handled by the OS? What if the (relatively complex and therefore much more likely to crash) OS crashes? Why would there not at least be some kind of basic thermal throttling implemented in hardware as a fallback? Oh wait, it's Apple, never mind.
It's managed by the Linux kernel communicating with a user space daemon (speakersafetyd). If the user land crashes or if the user space daemon is too slow the kernel can still fall back to a ridiculously low limit that will not damage the speakers for any audio. If the kernel crashes, well you get no audio in that case. IIRC the reason they couldn't do it completely in the kernel was because the temperature model uses floating point which is not allowed in the kernel.
In the late 2000s I remember hearing of PC laptops which if left in the BIOS setup would overheat and shut down due to the fan control being exclusively done by OS drivers, so this sort of "planned fragility" isn't exclusive to Apple.
I had one such laptop. It was always a crapshoot whether Windows updates (the big ones where it rebooted one or more times) would succeed or not before the laptop overheated and shut down. The reason was that the BIOS didn't do any power management and would always run the CPU at maximum power with the fans blowing like a jet engine. It was only once Windows (or Linux) was fully booted that they would take over and do proper power management. But the Windows updates were so slow that they would often spend too much time in that pre-boot environment leading to overheating and shutdown.
No one thinks "let the fans stay off and overheat" is a good idea unless they were convinced to do that against their common sense. Other manufacturers' models either had the expected automatic fan control via EC firmware, or defaulted to the fans being on some intermediate speed.
I wonder if there will be a similar issue with the displays when Asahi gets around to supporting HDR on machines equipped with FALD mini-LED backlights (or XDR, as Apple calls it). HDR displays usually regulate their brightness to keep the panel from getting too hot, and if Apple does that in software too then Asahi will need to replicate it.