ZH version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
68% Positive
Analyzed from 4665 words in the discussion.
Trending Topics
#linux#apple#hardware#asahi#support#macos#don#more#mac#still
Discussion (136 Comments)Read Original on HackerNews
> However, CS42L42 supports all the other common sample rates, and while the register layout and programming sequence is different, the actual values programmed in for 48 and 96 kHz are the same across both chips. What would happen if we simply took the values for all other sample rates from the CS42L42 datasheet and added those to the CS42L84 driver? As it turns out, you get support for those sample rates!
> The patch to enable hardware support for 44.1, 88.2, 176.4 and 192 kHz sample rates on both the input and output of the headphone jack was submitted directly upstream, and has been merged for 7.1. We also backported this to Asahi kernel 6.19.9, allowing users to take advantage of this immediately.
Nice bit of chip sleuthing and reverse engineering from the Asahi team!
> This is quite limiting, as it forces PipeWire to waste CPU cycles (and therefore battery life) on resampling audio streams that are not either 48 or 96 kHz.
So the Asahi team thinks that only supporting 48 or 96 kHz wastes battery life by forcing the software to resample audio streams. But why does Apple still do this? Presumably Apple has a very high commitment to save power and increase battery life.
https://github.com/hasenbanck/resampler#quality-analysis
This is presumably what Apple does. You kind of have to anyway or you have the stupid situation Linux used to have where only one app could play audio at a time.
When was that? I think my first Linux distribution was Ubuntu 8.04 and fairly sure it shipped with PulseAudio which in mind always been able to play audio from multiple sources at the same time, maybe I misremember?
I'm concerned that after all these years, it's still a separate project and not an effort sustained directly within the kernel mainline and mainstream distributions like Ubuntu, Debian or Fedora.
These kinds of reverse engineering projects are extremely challenging. With skills & field knowledge, it's "easy" to get to "80%" and have something useful for you and the most dedicated users. But reaching the "95%" required for a polished & general public ready experience needs nearly as much effort, often on tedious and time consuming tidbits.
That’s a big reason why progress slowed recently because they were focusing on reducing their diff count.
A lot of stuff has landed in the mainline kernel, but Asahi is how they keep experimenting on new functionality.
Yes, but also no? Because I think a reasonable argument can be made that ARM Macs are like game consoles with a more rapid generation: yes there are changes between each generation, but then you've got millions of units which are good for a very long time that are all near identical. Apple definitely is not changing everything between gens at all, work they've done for M1 has been plenty useful since. And support stretches awhile. The final M3 generation chip only came out about a year ago (the M3 Ultra for the Mac Studio was March 2025).
So sure there's ongoing effort needed for newer systems, and that may require ongoing RE more then typical. I don't want to brush aside the effort there at all. But at the same time there doesn't seem to be the same long tail of hardware variations and dozens to hundreds of players doing their own little tweaks either. Aside from memory and storage, every single Mac of a given SoC is the same so each time one gets covered they all get covered and are a stable experience. It's definitely a different thing then developing for PCs, and I definitely wish there was and support serious legal backing for no rug pulls being allowed, ever. Hardware owners should always have access to the root of trust if they want it. But that aside, I don't think their efforts are wrong or somehow wasted just because each new generation might need some new work. That doesn't appear from the outside to be intractable, and fact is the pace of hardware change for computers has slowed and continues to slow. A system from many years ago can still be very good for most tasks... so long as the OS can still be updated and work. Apple themselves seem more then limiting factor there, whereas Linux shines in long term support.
But that would probably result in burn out from the crazily talented dev team :P
I am curious what the boot situation is. It seems like Qualcomm actually has pretty good support for their cores. But since these PC systems sort of lack a bios, each one needing a hand built DeviceTree: it makes supporting them kind of a nightmare. Even a raspberry pi has a much more advanced and accommodating boot environment than these frustrating Qualcomm laptops. Alas. I don't know but I expect Asahi has to do similar hand tailoring. I am curious to know what the boot chain looks like! How much the system willingly helps vs how much hard to be bespoke hand coded system config! (Wish it wasn't like this, it's so bad)
What does this mean? Hardware support is rarely developed inside these organizations; what makes it seem like these groups would be a good home for this effort?
It makes sense to have a group of experts in a field (Apple hardware/firmware) contribute patches upstream, which is the exact system here. And Asahi have done an above and beyond job also maintaining their installation framework while carefully moving changes upstream as well.
The only way to get the battery life Framework advertised is on Windows' 'Ultra Efficiency' mode which cuts CPU performance by 25-50%, lowers brightness by 30% and deprioritizes everything in the background to such an extreme that responsiveness of those is measured in seconds.
It is not comparable at all to M-series or Snapdragon laptops happily chugging along at full capability and getting (compared to AMD / Intel) stellar battery life.
My variosu Linux adventures have always resulted in doing random patches for audio or screen incompatibility.
My windows days were plagued with battery issues.
I feel like most Linux ricers wishs for a MacOS-like experience, except with more customisation. (Which is entirely possible now with the ricing on Mac)
This is the kind of dated argument that really makes me dismiss most of the critics. I was running xubuntu as my main desktop since 2010 at least, switched to Debian + nix + XFCE in 2022 and switched to full-on nixOS in 2024. I never had issues with audio then and had to go out of my way to "break" audio on NixOS when I wanted to try pipewire instead of pulse.
> feel like most Linux ricers wises for a MacOS-like experience
I've put together a Hackintosh once, tried for a few weeks as the daily driver. Aside from being able to use tools that dealt with real-time audio processing, there was nothing else I wanted to copy or bring to my Linux system. It cemented my opinion that most software developers that keep touting the "superiority of MacOS" never gave a fair shot at Linux on decent hardware and were just rationalizing their prior choice.
Tried a different distro, it booted but no matter what resolution or refresh rate, the display showed severe artifacts when scrolling. Tried to fix it for a few days, gave up.
I am not a Linux novice, I have been using every major OS for decades at this point, and I’ll be damned if I didn’t install Windows, decrapify it, and everything just worked.
You can say I should have done more research on hardware compatibility or whatever, but I didn’t have to for Windows.
And I like how you complain most devs never give Linux a fair shot on decent hardware right after describing that you MacOS experience is a hackintosh. That makes a lot of sense.
Modern Apple laptops seem less special now but you also have to look at them through the lens of their introduction.
A similar thing is true for Sonos. They don't seem all that special now, but you have to realize they have been offering multi-room synced audio with a good UX since 2006. That's before the iPhone even was released.
Some people seem to get better battery life with Windows than with Linux.
Most users on any OSes are not ricers. Most of my customisation is functional - panels and widgets placed for practical reasons. A lot of people do not seem to customise at all, or barely.
Definitely good to have the option, but you'll most likely never get quite the same performance or battery life on linux
Is that on Mac hardware? I run a 14 year old Mac Book Air, and it works flawlessly with the latest Nixos, and has done for the last 11 years.
If you have issues on random PCs, it's because there are an enormous variety of them out there, with all kinds of incompatibilities that have to be worked around. On Mac hardware, there tends to be a more restricted number of variants, and after a few years, Linux becomes rock solid on them.
So the OP is correct, Linux on Mac hardware is the best combo.
M series Macs are still very much a work in progress. I'm typing this on one, in Linux, so plenty of things work, but not for example USB-C output to an external display, and a lot of the processor power level / suspend stuff is still not fully there so battery life is quite a bit worse, especially when suspended. I think the situation is rather worse on the latest generation hardware, too.
I was burned by the 2016 MacBook Pro keyboard, and once Liquid Ass was announced I knew it was time to get out.
Sold my MacBook Pro M2 Pro, which has a stupid gigantic notch that blocks the menu bar items with no built-in mechanism for getting to them when they overflow.
Now I’m on a Framework 13” and I’ve had zero issues with Linux. Everything just works. KDE Plasma is way more customizable than macOS or Windows. I’m finally able to ditch slow Homebrew and use a real package manager. I can finally play light PC games on my laptop without dealing with streaming or Crossover.
My preorder is in for the Framework 13 Pro, which looks to get even closer to delivering a MacBook Pro for Linux. Meanwhile, Apple hasn’t changed their chassis design in 5 years, while Framework updates their hardware constantly while maintaining cross-compatibility. A company with less than 500 employees is catching up to a trillion dollar corporation.
I’ve already got my fully modular LPCAMM RAM delivered and ready with no Apple tax. I’ll get better battery life watching YouTube videos than a MacBook Pro and the graphics are just as powerful as the M5 base chip.
And if something breaks I won’t have to deal with the nightmare I went through with my 2016 MacBook Pro.
Works like rocm seem so close. But you need either the pre-compiled packages or 2+ year old Ubuntu to compile them. https://github.com/ROCm/TheRock/issues/3477
All the classic reasons ("competitive advantage", "secrets", etc) do not hold water in this day and age.
Apple documents lots of things the genius bar won't help with. For example, Apple provides instructions for compiling custom builds of the XNU kernel. Even so, if you replace the stock kernel and your Mac kernel panics, the genius bar isn't going to help you. (Maybe they'd help you wipe the computer and restore everything to stock, but I imagine they'd do that if a Linux user walked in too, today.)
I suspect Apple hasn't shared documentation because it would take time to clean up for external release (legal stuff, plus not accidentally leaking future products). What I think Apple should do is make an engineer available to talk on the phone for a couple of hours a month, which should amount to a rounding error in their budget.
What do you mean by needed? A lock-in is more profitable so is needed to maximise profits.
The laptop has various pieces of hardware in it and corresponding drivers in macOS to make them tick. Did we buy the hardware and the drivers as an inseparable package, or should we be provided with the manual to make one component work when the other breaks, be that either third party trackpads or third party (Linux) drivers.
Apple might argue that drivers, unlike gears or motors, will never wear down and fail. They won’t need repairing so you don’t get to know how they work. Does right to repair only apply to products that could ever need repairing? Does it also extend to knowing how your purchased product is built so that you could repair it?
Maybe we’ll see a test case some day when a cosmic ray blows out /System/Trackpad.kext and a litigant applies to a court for the documentation to repair their laptop — to write their own driver!
(Or vice versa: a manufacturer of coffee grinders arguing in court that they are exempt from right-to-repair because they repair their machines for free at their Genius Espresso Bar.)
Could I then submit a warranty claim and demand Apple replace my aging laptop with their latest model?
Apple's MO is that it's their baby. End of. They don't do open. Their compiler is closed source, and so on.
Important context to understand why.
I'm running asahi on my macbook. And never touch OSX. I wouldn't even had gotten it if asahi wasn't so well supported.
There's a portion of another market: people who want to run Linux and want a powerful laptop who buy x86 Laptops right now. Apple could expend very little relative effort while offering no official support by helping Asahi get that to a first class platform. They won't capture them in the ecosystem (and they never would have) but will still benefit from hardware sales to them.
Obviously, if they sold their hardware at a loss and subsidized that with ecosystem capture that would be a non-starter. But from everything we know, the hardware itself is very profitable.
I’d love to dual boot Linux too but I’m under no delusions about being a very small segment of the Mac population.
We really need to retire this phrase, it’s become a humblebrag way of calling the other party delusional without even trying to understand.
The list here though is long: priorities, accuracy concerns, blurring the line on official support, IP restrictions with third parties (even Apple uses plenty of licensed cores), etc.
either Asahi gets there from the software side or Framework gets there from the hardware side
I wonder if there would be interest in an Asahi Remix spin focused on a more Mac-like out-of-the-box experience: cmd as the main modifier key, Mac-like keyboard shortcuts, theming, gestures, etc.
Of course, you can tweak any distro however you want, but I think a curated default experience is a different thing.
Ok typical X/Wayland setups, Cmd is already the main modifier for DE features, while Ctrl is the modifier used at an application level.
There would be a lot of weird overlap with changing that.
DE features don't matter at all outside of cmd-tab and whatever the equivalent of spotlight is. The application level is the main modifier, and changing them all to cmd is essentially impossible at this point. A detail Haiku got just about perfect, I think.
Either way, ctrl as a gui modifier is a dealbreaker for me. It also breaks the use of readline keybindings for text entry.
Look forward to switching back to Asahi full time soon!!
> finding their way into the Asahi kernel tree are patches to enable more hardware on M3 machines. This includes support for PCIe, MacBook keyboards and trackpads support, the SMC-based RTC and reboot controller, and the NVMe controller, courtesy once again of Michael Reeves and Alyssa Milburn. This brings Linux support for the M3 up to roughly the same level as the first Asahi Linux alpha for M1!
The fact, that there has to be a macOS partition for maintenance ruling out ZFSBootMenu somehow is very unfortunate - but I've accepted it.
Maybe the new Framework 13 Pro will be at least in the region of an alternative... :-/
am I just a smooth brained dumb dumb that has drunk the koolaid? perhaps. but I don't lose sleep on it and am not tinkering with hardware, or software anymore, I just get stuff done now.
[1] https://github.com/AsahiLinux/AsahiLinux.github.io/commit/e0...
Not to just shit all over him or anything, but it really sucks to see someone who is genuinely top-ten-on-earth when it comes to "real hacking" struggle so much with socialisation and mental health.
I still want to run it on an M3 MBP so it's nice to hear progress on that is happening.
They do currently ban LLM-assisted submissions. To be honest, even if LLMs are technically capable of writing code that assists the project, this at least helps keeps the 'floodgate' closed for certain low-quality PRs that other open-source projects are getting.