Earlier quoted context omitted.
> And a completely unreleated thought, maybe it is > possible to remove the safetly limits on speakers > of other brands and apply the same strategy to get > better sound? That’s a really interesting topic. I hope an audiophile shows up to give some thoughts.. Probably want an audio engineer instead of an audiophile hobbyist, for a more proper and informed opinion. =) However, as an audiophile hobbyist, getting good…
> as an audiophile hobbyist, getting good sound from bad hardware (or excellent sound from good hardware) via DSP is definitely a thing! Acknowledging this lifts you out of the category of "audiophile" into "person who actually knows about audio" ;) There's a lot of what I can only describe as outdated prejudice about what can be achieved with class D systems. Your explanations in this thread are excellent. > I would…
A reason why Mac speakers sound better and louder than most
281–290 of 301 posts
Re: A reason why Mac speakers sound better and louder than most
#282Earlier quoted context omitted.
Isn't it for Linux? I thought Macs use MacOS. Again I feel like I'm reading something out of context.
I think the context that you're missing is that the author of the post is one of the main developers for the Asahi Linux project that is porting Linux to the Apple M1/M2 family of Macs. They're trying to implement for Linux software support for all the Mac hardware capabilities that macOS already supports. Since the speaker safety model is apparently done in software under macOS, an equivalent needs to be reverse eng…
Re: A reason why Mac speakers sound better and louder than most
#283Earlier quoted context omitted.
So is the thesis here that there is no other way to have non-crap sound on a laptop than this Apple patent? No alternative? No patent-non-infringing approach? Because if not, the real reason is as the author suggests: other manufacturers don't bother. I have been working a long time - decades - in a part of the industry that is not just patent happy but patent berserk and it has never been my experience that other ap…
I’m not saying there might not be another way. But iTunes and the other big music distribution power players have requirements and use encoding technologies based on loudness rather than power. [1] This is why your playlists don’t require adjusting the volume between songs from different artists/albums/eras/genres. So it is likely that Apple’s method works hand in hand with the technical constraints of iTunes require…
Re: A reason why Mac speakers sound better and louder than most
#284Earlier quoted context omitted.
I’m not saying there might not be another way. But iTunes and the other big music distribution power players have requirements and use encoding technologies based on loudness rather than power. [1] This is why your playlists don’t require adjusting the volume between songs from different artists/albums/eras/genres. So it is likely that Apple’s method works hand in hand with the technical constraints of iTunes require…
How many people are using their macs to listen to iTunes? I get YouTube, Netflix, anything you can watch on chrome, but iTunes is more of a phone, home pod, Apple car thing, and even then many people use Spotify rather than iMusic. Are other providers using QuickTime or similar encodings for non-Apple provided media?
All the streaming services normalize music on loudness.
That’s why you aren’t constantly adjusting the volume of your speakers/headphones to compensate for the way each song was originally mixed and mastered.
Apple/iTunes got there first.
Re: A reason why Mac speakers sound better and louder than most
#285I wonder if malware could bypass the speaker safety daemon and potentially damage hardware or even start a fire? Looks like Apple is relying too much on TrustZone and Secure Boot to prevent physical hardware damage? Also, Apple can now say that jailbreaking the devices could present a physical safety issue. So one more reason for making jailbreaking illegal?
2. Apple doesn't implement TrustZone. They don't even implement EL3 (the exception level typically used for TZ) in their Arm core designs, just EL0 (userspace), EL1 (kernel), and EL2 (VM monitor). They appear to have completely rejected the concept of an above-the-OS supervisor responsible for security and other system maintenance tasks, which is the idea behind things like TrustZone and Intel's insane System Management Mode.
3. One of the fairly novel things about Apple's Arm Macs is their secure boot infrastructure. Although it's clearly derived from iOS secure boot, it has been greatly extended, in part because (contrary to what you assume) Apple doesn't believe Macs should have to be jailbroken when users want to run something not signed by Apple. See this for more details than you probably require:
https://support.apple.com/guide/security/startup-disk-securi...
So, no jailbreak is required to boot Asahi Linux, or any other unsigned OS. Note that while Apple's documentation refers to booting an unsigned "XNU kernel" (XNU being the macOS kernel), the binary doesn't actually have to be XNU. In Asahi's case, it's a bootloader which loads another bootloader which loads the Linux kernel. (IIRC - I might have that chain a bit wrong.)
Also, if you want to take the time to read through all of that link, you'll find Apple did put a lot of thought into making it possible to bypass while simultaneously keeping it quite robust against malware. Barring truly horrific implementation flaws, it should be impossible to remotely automate the bypass, and the procedure is designed to provide some level of warning to victims of social engineering. And, it's a per-OS preference, so you don't have to reduce the security of your macOS install at all if you just want to play around with Asahi on a different partition.
Even more interesting - the low-security "unsigned" boot path is technically still signed, in a very useful way. Attesting that you'd like to boot an unsigned "XNU kernel" stores the "XNU" binary's cryptographic signature in Apple's Secure Enclave. Every time you boot it, its signature is checked to make sure it hasn't been modified since you authorized it. Which means... if that binary is a loader which does its own cryptographic signature check on the next stage loader, which does its own check on the next stage (or Linux kernel etc), you've built your own secure boot chain on top of Apple's, without having to ask Apple to sign anything. Pretty cool.
Re: A reason why Mac speakers sound better and louder than most
#286Earlier quoted context omitted.
I think it's more that Apple has dropped down to normal reliability levels. With Apple's focus on shipping a new OS every year no matter what, they have started shipping broken features by default, and you just have to hope they get around to fix the bugs next year.
Mountain Lion please, 3 years in a row. My new battle is that Apple Mail search just stops working. Quitting and reopening doesn’t do anything. When it works, it’s almost like crafting the ultimate regex at times.
One thing though, software quality has been falling down a lot, including Apple’s
Re: A reason why Mac speakers sound better and louder than most
#287Earlier quoted context omitted.
On the M2 Air (and new design MBP), speakers bounce the sound off the screen. I think if you were to remove the screen and listen to those speakers in open air it'd sound quite odd. Probably they're pre-distorting the sound so it's correct only after bouncing off the screen, kind of like how VR distorts the image to account for headset optics undoing that distortion. I had an M1 Air before the MBP release. The sound…
Does the laptop have knowledge of the screen angle, or does its calculations just assume an 'average' angle? Or does it not matter too much (it seems like it would to me)?
Re: A reason why Mac speakers sound better and louder than most
#288The idea of feedback-based userspace software thermal management like this seems suboptimal to me — the failure modes are nasty. (By feedback-based, I mean using V/I sense from the amp.) The goal is to prevent the voice coil from overheating, ever. So some kind of calculation runs at some interval t, and it needs to ensure that, over the upcoming time t, the input to the amp can’t possibly overheat the coil, and of c…
There's no distinction between "user" and "kernel" that would mean kernel code gets scheduled more reliably than realtime userland threads. Or even that it necessarily has better access to the audio hardware. If it's really really important then you'd want to move it to a custom core on the SoC of course, but that'd make a Linux port harder.
The distinction is that the kernel submits buffers to hardware, so it can do safety-related checks synchronously. If it doesn’t get scheduled, nothing plays, and the tweeters don’t burn out.
This can be done in userspace, too. Something in the kernel (ALSA? A driver?) could call into what would be, in effect, a userspace audio codec driver. That userspace driver would do its safety checks and then send the buffer off to the codec for playback.
It’s a bit sad that x86’s abysmal context switching performance has helped nerf microkernel and userspace driver development for years. Fortunately we’re talking about ARM64 here. (On modern systems, the tens of thousands of cycles x86 spends doing nothing useful when context switching or handling interrupts don’t matter as much as they might have when CPUs we’re slower.)
Re: A reason why Mac speakers sound better and louder than most
#289>Oh yay, HN found my post. I don't do HN any more, but to answer some of the comments there:
We now have fewer expert on HN and HN is fast becoming another Reddit.
Re: A reason why Mac speakers sound better and louder than most
#290Earlier quoted context omitted.
Appreciate the clarification - like I said this is well outside my area of expertise and my eyes glazed over pretty quickly in reading but at this point we're borderline in semantics. Exactly. In this case it's a "process". Generally speaking my take is there's almost never entirely new process (or design or anything else) in any "invention" - humans have been at this for hundreds of years and there's almost nothing…
It's well outside your area of expertise which is why you started with a "well actually" post claiming the article is obviously false?