For DSP, we already can do that using something like Easy Effects[1][2].
Unfortunately, this isn't shippable for distros. The biggest issue is acquiring proper impulse-response data. In theory, it has to be tuned per-model, and turning basically requires pro-grade equipment and a recording studio. However, apparently many people assume Dolby is using the same profile for all laptops, so just copy-paste the same file here and there. Not really sure which is the real case.
Anyways, Asahi can ship DSP turned on by default because the distro is specific to Apple. That's how Apple boosts the quality of its hardware, and the same applies to a distro dedicated to it.
This doesn't contradict what you're saying, but it's worth noting: speaker support on these laptops couldn't be done through Easy Effects, and speakersafetyd does way more than just DSP. There is no safety mechanisms built in to the hardware/firmware to prevent blowing out the speakers, so speakersafetyd needs to ensure that stuff doesn't get too hot; and that can't be done with a simple volume cap either, since the speakers sound terrible when driven at a guaranteed safe gain level. You need software with a model of how the speakers behave to monitor sense data and dynamically reduce the volume when the audio would otherwise have made the voice coils dangerously hot.
And the system needs to be fail-safe, so that the speakers don't get blown out if the daemon crashes or hangs.
---
As a separate topic, I disagree that this isn't shippable for distros. Distros already have a bunch of hardware-specific stuff. Libinput, for example, has a hardware database to correctly handle or work around quirks for all sorts of input hardware.
There's absolutely nothing which would prevent Ubuntu from providing speakersafetyd's hardware database, either as an optional package, or, if out-of-the-box Mac support is important, as a package that's installed by default.
> Libinput, for example, has a hardware database to correctly handle or work around quirks for all sorts of input hardware.
As a complete aside unrelated to the broader discussion, libinput is my nemesis and it has degraded my user experience of Linux.
I hate, hatehatehatehate one finger tap to click. It's a huge misclick generator, and libinput used to have it off by default for good reason.
However, libinput gates all actually useful and not very error-prone gestures like two and three finger taps to right and middle click and multifinger swipes behind having one finger tap to click enabled. You either take it all or you get nothing.
This is a huge regression from the old Synaptics interface which let the user freely assign different actions to taps with different amounts of fingers.
The worst is that it's completely intentional and has been the case for over five years because the old maintainer didn't want to write tests.
I also take issue with parts of libinput... there are things which are relegated to the hardware database which should 100% be config options. I don't mind the idea of having a hw database, but if I as a user disagree with a choice made in the hw database, I should be able to easily change it. It sounds like the "all or nothing" tap to click stuff fits the general vibe of not letting the user configure stuff too much.
I also dislike how there's no global libinput config file. I get that it's supposed to be a library, and the user of the library (GNOME, KDE, Sway, whatever) is supposed to expose those options, but in practice, a lot of useful options aren't exposed to the user. GNOME is especially bad about that.
There are also weird choices, like: when you press down with two fingers and then move those fingers together (double click and drag), the cursor moves at twice the normal speed.
Linux input isn't universally better now than it was a decade ago and that sucks.
> Anyways, Asahi can ship DSP turned on by default because the distro is specific to Apple. That's how Apple boosts the quality of its hardware, and the same applies to a distro dedicated to it.
Aww, so you don't think other distros will ship this even once upstream is figured out?
Kernels already ship hardware-specific drivers, but I suppose that just comes with the Linux kernel, whereas this needs support on both the kernel and userspace sides...
If a distro is shipping an image specific to macs? sure
If a distro is expecting you to install onto the rando asus gaming laptop you got at staples? not going to work.
The thing about M-series apple macs is there are only like 10 models total to record profiles for. You can't realistically do that and ship profiles for every x86 laptop under the sun.
I am at a complete loss how this is any different or harder than shipping hundreds of bits of firmware or hundreds of quirks for random hardware (have you seen the entirety of the quirks tables in the Linux kernel) all based off hundreds of drivers shipped with the kernel.
You maintain profiles in a repo and package them like anything else. No one has indicated how this cannot usually be zero config via hardware probing.
You have to actually measure a profile to ship it.
That means sitting down in front of every single model with decent measurement equipment and running a test. This doesn't scale, especially not for a distro with limited resources.
Huh? Distros don't produce the overwhelming majority of the software or configuration they ship. There's no reason individual distros need to be part of this effort.
This can scale with a central repository that any organization including manufacturers or suitably equipped individuals can contribute to. It just needs to be permissively licensed. The major distros or associated vendors such as Redhat or Ubuntu certainly have the resources to host such a thing and so does the Linux Foundation.
How are you applying that to the Asahi packages though? They're just packages for Fedora, a pretty generic distribution, and ArchARM, which is also meant to be installed on Raspberry Pis or Chromebooks after all. I know it because I run it on both Raspberry Pis, my M1 and a Hetzner server.
it seems like precisely the contrary to an Apple-specific distribution.
I'm not. I'm talking about shipping profiles for rando x86 laptops.
There are a fuck of a lot of rando x86 laptops, and you need to record a different profile for every single one of them. That means sitting down in front of every single laptop model you want to ship a profile for and running tests with a measurement-grade microphone and equipment.
Marcan did that for the handful of M-series mac laptops that exist. Good luck physically testing even 0.01% of the x86 laptops that exist.
You don't need to test every model of x86 laptop, just the most popular ones!
I have no data on this, but I would guess that the top 10 or 20 best-selling x86 laptops comprise a very significant portion of the overall market. So profile those, ignore the others, and you've helped a lot of users!
Honestly, this sort of thing should be considered “shippable”, and the fact that it isn’t has been holding Linux back for 10+ years.
I’ve been waiting decades for a Linux distro that just buys a few commonly produced laptops that are likely to be produced for a few years, and then tests the crap out of them and applies this sort of polish.
Current gen thinkpads probably would have fit the bill for the last ~30 years, for example. I was hoping the pinebook pro would be this, but it has a few severe hardware issues (suspend battery life, DSP noise) that don’t look like they’ll be fixed. Similarly, the XPS line has the capacitor whine problem, and are based on Intel (which has been exclusively shipping power hungry hot messes for the last 10 years).
If the M[1-3] end up being the models where Linux finally gains stable support for reasonable laptop hardware, then so be it.
The value proposition of M2 and M3 have been comparatively weaker, but on launch, the M1 macbooks blew everything else out of the water in terms of bang for buck, IMHO. You could perhaps beat them in terms of raw compute, but once you factor in the 120Hz HDR panel, excellent keyboard, sleek but still relatively robust chassis, it's an all-round winner.
Of course, it lacked Linux support on launch, but that's why the Asahi project is so great. It's providing that missing component of system integration.
Framework, System76, etc. are producing some cool laptops, and I'd consider them if I were looking to buy a new laptop today - but I'm not. I have an M1 Pro MBP in my hands right now, and I have no need to upgrade it any time soon.
Until you factor back in buying a usable config. And the fact that Asahi is still not totally feature complete. Three years on and DP alt mode for example is still a WIP.
>I’ve been waiting decades for a Linux distro that just buys a few commonly produced laptops that are likely to be produced for a few years, and then tests the crap out of them and applies this sort of polish.
nearly every major distribution does this to some degree and has had for years and years; whether or not you're happy with that level of 'polish' is another thing, though.
> I’ve been waiting decades for a Linux distro that just buys a few commonly produced laptops that are likely to be produced for a few years, and then tests the crap out of them and applies this sort of polish.
I suspect that the laptop market is far too fragmented to make this worthwhile
Do you know how many different models of laptop that HP alone is currently selling? One Hundred and Twenty. And that list has regular churn. You might think they'll all be using the same firmware and chipsets but you would be wrong. There are dozens of configurations, some older, some newer, some higher performance, etc... It's a huge mess.
I know. So take OpenBSD for example. That works best on older Thinkpads. For developers personal use they focused on making those work well enough. They care less about the other models of Lenovo laptops. For Dell you would focus on XPS only, for example.
> I’ve been waiting decades for a Linux distro that just buys a few commonly produced laptops that are likely to be produced for a few years, and then tests the crap out of them and applies this sort of polish.
So who is going to do all that work?
I bought a laptop that has RGB LEDs in the keyboard. I didn't particularly mind not having control over them on Linux but the problem was they defaulted to the brightest purest blue color imaginable. Booting Windows just to run the shitty manufacturer's software was unsustainable so I reverse engineered it and made a Linux user space driver with libusb.
That took a significant amount of time and effort. Just a bunch of LEDs, it seemed like a simple task. I actually had to record the USB messages with wireshark and then figure out what they meant, correlating the bits sent with my physical inputs. Hundreds of LEDs.
I simply can't fathom what it would take to apply polish like speaker safety to my own laptop. I honestly didn't even know there was a safety risk involved before I read this thread. Do these Linux distributions really have so much money in the bank that users can expect them to buy hardware to test stuff like this on? It's hard enough to ship software that works at all.
"I’ve been waiting decades for a Linux distro that just buys a few commonly produced laptops that are likely to be produced for a few years, and then tests the crap out of them and applies this sort of polish."
There's a confusion here regarding "shipping". What I wanted to talk about was shipping a distro (integrated with DSP + profile) as a whole, not shipping software component. My original comment is clearly touching the integration b/w SW and HW, which common x86 distros normally don't enjoy, and shipping with DSP fully integrated (w/ zero friction UX) is very difficult for them. The situation may change if laptop vendors actively involve in the development of Linux distros, but, as of now, the bazaar model is the only answer, and it's painfully slow as noted by the release note here.
EDIT: Also, about recording IRS: both the mic and the room environment impact the response data. Using cheap mic in your room does introduce distortion.
However, I realized I was kinda making an assumption that IRS was being recorded for effects. If you're just flattening the response curve, they should work mostly fine. This can become an issue if it's used for effects (e.g. mimicking 2ch Dolby Atmos) because the distortion can be amplified by the environment.
Also, in the long term, using a standardized setup helps with maintaining the quality of IRS. You really want to be able to reproduce the setup, so that you can further improve the data. It's better than subjectively keep fiddling with EQ sliders.
I wonder, can't distros provide pipewire configs and patches? I've had great success with my laptop (other maker) with both a kernel patch for DSD and a quite straightforward pipewire config (the filters.avail folder has examples for Dolby surround!).
Unfortunately, this isn't shippable for distros. The biggest issue is acquiring proper impulse-response data. In theory, it has to be tuned per-model, and turning basically requires pro-grade equipment and a recording studio. However, apparently many people assume Dolby is using the same profile for all laptops, so just copy-paste the same file here and there. Not really sure which is the real case.
Anyways, Asahi can ship DSP turned on by default because the distro is specific to Apple. That's how Apple boosts the quality of its hardware, and the same applies to a distro dedicated to it.
[1]: https://github.com/wwmm/easyeffects
[2]: https://stackoverflow.com/questions/27122564/which-version-o...