Can someone ELI5 why advanced speaker DSP is a huge thing? I read the linked document and couldn't really figure out why this is important and why it differs from what we already have in Linux systems.
Manufacturers can do a lot with DSP to make small speakers sound better. But "advanced" is saying a lot here. Recent speakers in macs and macbooks are over-driven to sound better and louder, with the DSP modeling energy input to the speaker and temperature of the speaker and keeping it within its physical limits. Without this DSP, the speakers not only sound terrible but become physically damaged if you try to use them at more than a very low volume. Any modern smart speaker or smartphone you buy will use similar DSP to sound much better and louder than it ought to, given its size. I think other laptops also do something similar at the hardware level.
Rightly or wrongly, Apple does it in software on the CPU but until now this wasn't replicated in linux. So the Asahi project (which is for macs with M1/2/3 CPUs), has added this feature to linux[1] and is working on adding DSP models for each model of Mx Mac. In Asahi Linux Speakers have been disabled by default on all models until this feature as well as the specific DSP for each model is ready. Now they have reached the point where speakers are enabled for the first model, which is a huge milestone.
[1] I originally wrote "linux kernel" but it is actually done in user space, with interlocks in the kernel to fall back to simple aggressive volume limiting.
No because you make the models conservative. In the link marcan mentions they will improve performance over time (presumably partly by making the models less conservative) and are "shipping with a hard volume reduction limit of -7dBFS to catch potential bugs or misbehavior."
So speakers have a worst case maximum power and sound profile. That is the bounds that if you never exceed you will be safe. But if you push past those worst case bounds, now you are entering a dynamic system where things like temperature start determining the actual bounds of the hardware and the points where stuff starts causing damage.
Apple provides a system that drives the speakers within those bounds as close to the actual bounds as possible to get the most out of the system that they realistically can.
Asahi is trying to do the same but are choosing a profile that is far more conservative than apple to start with while they get things ironed out. This profile they have is still an improvement over the worst case bounds but it has very sharp/jarring "safeties" that trigger when the system suspects it might be close to damaging the hardware (dropping immediately to a much lower, safe level vs apple's profile which gradually shifts the audio to a safe point without making it obvious that it is doing so).
You could say Asahi Linux was very conservative about this because they disabled speakers altogether until now.
It’s ok to be quite loud for any one peak for a short amount of time (let’s say 50dB for 10ms) but for indefinite time periods much less is ok (let’s say 30dB but these are totally made up numbers). There are also limits to how much energy you can put into the speaker before it overheats. There also may be some frequencies with different limits (this is total speculation on my part). So the DSP models the behavior of the speakers and tweaks the input to prevent them from overheating (in my understanding). Normally you won’t notice this unless you are trying to play a single tone at max volume. Without this advanced DSP, you would have to just limit the output to 30dB which in practice means high volume parts of your audio are clipped or you limit to a very low volume to have enough headroom to play the louder components of your audio. Considering how loud and good modern macbooks, smartphones and smart speakers sound compared to similar sized speakers from even 10 years ago I think the effect is pretty great.
The real answer to this question is yes. There’s a caveat by the devs that their safeguards make bugs unlikely, but a bug here means permanently damaged hardware.
The main reason DSP is a big thing is because Linux has never focused on it - Google has with Android and ChromeOS, as has Apple and Windows, but Linux speaker audio has always paled in comparison: https://social.treehouse.systems/@marcan/111230163766956867
That leaves it up to the laptop vendor to implement hardware to perform DSP (and the quality of this varies tremendously from poor to OK). Apple doesn't use hardware for their speaker DSP (it's all software) and their speakers sound better than anything else out there. Linux now has similar functionality thanks to Asahi, and it will only get better over time.
It's a huge thing because you can't really fit all the big speakers and audio stuff in tiny laptops and make them sound good. So we use extra steps (the DSP for example) to adjust how the speakers and amplifiers are controlled. Doing it this way allows us to have much better sound from tiny micro speakers. This is important because the alternatives are:
- Bad sound and nothing you can do about it
- No sound at all
- Carry external speakers with you all the time
Where in the past it was impossible to both have physically small devices and good sound, technological advances have enabled us to do more with less. So adding that technology means we can now have better sound than in the past.
The way I understand it, the tiny speakers in laptops don't sound great. But since sound perception is somewhat relative, manufacturers use DSP to try to improve the perception of the sound.
Of course, this will never rival an actual "serious" amp and speakers, but it can drastically improve matters. Anecdotally, my HP laptop has a pretty crappy sound under Linux, but under Windows with the Realtek drivers, it sounds OK. The soundcard itself doesn't seem too bad: if I use a pair of nice headphones or plug it into my dedicated stereo, even under Linux I hear no difference compared to using an external DAC connected through USB.
But we could already do DSP with Pulseaudio and Pipewire. I guess is making the speakers DSPs "built in" and tweakable with GUI etc? As well as actually creating the speaker DSP profiles, I guess.
The speakers safety thing seems like a completely new thing, though.
All sounds like an absolute nightmare to anyone even remotely into audio. But I guess tiny speakers are occasionally useful.
In this, our modern world, tiny speakers are what most people listen to most things on, except maybe in their cars.
Phones, laptops, tablets. The tiny speakers built into TVs, much smaller than even built-in speakers on CRT TVs used to be. Ear buds of various sorts, and smallish headphones. That’s most audio-listening accounted for (except in cars).
Hell, I’ve got a good hi-fi setup and (separately) a probably-top-couple-percent 7.2 home theater audio situation (in one room… but not on the other TV) and even so I listen to things on tiny speakers more than on big ones.
> In this, our modern world, tiny speakers are what most people listen to most things on, except maybe in their cars.
Hmm... I think you're probably right, but the one thing that gives me pause is the enormous market for Bluetooth speakers. I see Bluetooth speakers everywhere! I suppose most Bluetooth speakers are still "small" in the grand scheme of things, but they're certainly larger than phone and laptop speakers.
Earbuds are similarly omnipresent. I'm not sure it's accurate to classify those as "tiny speakers"; the physics are different, because they only need to be loud enough to hear when they're next to your ears.
Good bluetooth speakers also use similar DSP to sound way better and louder than they would without it so I am not sure this is a counterpoint. The unique thing here is Apple does it on the main CPU, presumably because "why not", so you couldn't safely power the speakers of your mac while running linux until the related features were added.
At this point even "bigger" speakers make heavy use of DSP, too - from household commodities like Sonos to higher end hi-fi powered speakers like the KEF LSX series, almost everyone in the industry making an active-amplified product has wised up to the idea that some processing can make use of clever acoustic tricks or compensations to make their products sound better (by whatever definition of better their brand sells) than they would being drive flat from the source. When you provide the whole integrated package its a no brainer.
Compensating physical limitations to create a neutral sounds profile is useful regardless of the size of the speaker.
I have a custom-made subwoofer that can hit 12Hz (measured), and creating a DSP profile to compensate for my room + speaker acoustics has significantly improved the listening experience.[1][2]
It's primarily EQ calibrated via a frequency sweep of the room + speaker acoustics.
The hifiberry DSP does primarily three things:
- equalization for speaker + room acoustics
- customizable crossover frequency for speakers (in my case a 2.1 setup)
- loudness equalization across speakers
There may be a latency compensation module, but that's not something I needed in my case.
None of this is rocket science, but audio does sound significantly better after compensation. Specifically, my living room geometry was causing standing waves in the ~200 Hz range, making the low-end sound unpleasantly boomy. The calibrated compensation pretty much eliminated this, without needing to invest in physical sound traps and the like.
This is a fun little project for really not much money. I recommend it to everyone who likes tinkering, all you need is a <$100 measurement mic, REW, and a tiny bit of patience.
If your standing waves mean you only need to attenuate frequencies with EQ then you're very lucky! A standing wave means there will be some parts of the room that are too loud (antinodes) and some that are too quiet (nodes). Bass traps are to eliminate standing waves such that you won't have this variance around the room. The bigger problem is when your sitting position is in a node meaning you will completely lose a bass frequency. You can't EQ that back.
EQing out bass if you sit in an antinode is definitely better than nothing, though.
You're right that you can do DSP everywhere, but if you implement this in user space you give everybody rights to damage the speaker.
It's not only useful for tiny speakers: everything from home audio to big PA installations for concert halls can benefit from DSP optimisations. It's a way to squeeze more sound from the same speakers.
I think it's supposed to be a kind of in-kernel equivalent to Pulseaudio and Pipewire, meant to keep the sound output below the limit where it would risk blowing the speakers. That's a nice idea, and you could even pick a cool name for it, like Advanced Linux Sound Architecture. It could even support things like the hardware mixing channels, filter chains, sample-based synthesizers etc. that some soundcards have, instead of leaving it all to software.
I do use DSP under Linux with easyeffects. I found a preset called "Laptop Unsuck" which works ok-ish, but I can't find the original URL after a quick search. It works OK for my needs, but easyeffects does add some latency, which isn't great for videoconferencing for example.
However, most people will probably not go out of their way to use this, and also, having a DSP tailored to the specific speakers and enclosure is nice. But I agree there should be a way to completely disable this, at least when using the line out jack, be it for headphones or an external audio system.
> But I guess tiny speakers are occasionally useful.
They are to me. My laptop is much easier to carry on planes than my audio system, and I don't always like having headphones on, for example when watching a movie in bed.
> But I agree there should be a way to completely disable this, at least when using the line out jack, be it for headphones or an external audio system.
According to Marcan on mastodon, the DSP is only enabled when you use the internal speakers.
I think the idea with the M-series laptops in particular is that you can drive the speakers at volumes that actually damage them very quickly ( see https://github.com/AsahiLinux/linux/issues/53 ). The idea AIUI is that you can use a DSP along with a physical model of the voice coil to get better sound than you would if the speakers were volume-limited.
I don't know how common this arrangement is in other laptops, but it's the kind of hardware/software integration that Apple is known for.
It isn't just dynamic range compression. This is actually driving the speakers beyond their safe limits for sustained output as long as the temperature estimate (a function of the specific speaker's characteristics and the recent history of the signal it's been fed) is safe. "Dynamic range compression" doesn't imply any of that.
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!).
For what it's worth, it's very clear to me which is better even on my iPhone's speakers (as well as on my desktop's "real" speakers, of course). Sound preferences are deeply personal, but I'm still pretty shocked GP can't tell.
This is actually a common misconception. In blind testing, the average listener reliably prefers the more accurate speaker. There is a talk [1] by Dr. Floyd Toole that is an excellent crash course on the science of sound reproduction and listener preference.
I listened on a calibrated speaker setup and on my good Sennheiser headphones. Yes, there’s a difference, but both sound like shitty speakers just with different EQ profiles applied to it. It's still compressed to hell and extremely tinny no matter what.
I agreed with this so I made the levels equal (as measured objectively with EBU R 128): https://0x0.st/HvXA.wav
The first (DSP processed) clip still sounds much better to me. The first time the unprocessed clip is played it's rather noisy for some reason, that could be room noise picked up in the microphone though. The high end is missing from the second clip almost entirely (anything above 5 khz).
However the DSP clip isn't without significant problems. It sounds distorted to my ear, and slightly pitch shifted as well. It's rather "tinny" sounding. I'd rate both clips extremely annoying to listen to in comparison to the original which seems pretty well mastered if you like this sort of thing: https://youtu.be/ZRtdQ81jPUQ?t=52
It's hard to tell how much of this is due to it being a quick and dirty recording. Also, being able to play audio at higher volumes is supposed to be one of the big advantages of using this DSP chain, since temperature spikes created by transients are managed in software. (Just speaking for myself personally, I've never felt that my non-Apple laptop speakers needed to be louder, even without DSP.)
The big issue I see with trying to compare the DSP profiles of two different clips, as recorded by a cheap consumer microphone in a compressed audio clip is that we're unable to tell whether asahi's DSP is actually better or just happens to match the sweet spot of the phone's microphone DSP profile.
That's precisely the issue I've got – yes, there’s a difference, but both sound like shitty speakers just with different EQ profiles applied to it. It's still compressed to hell and extremely tinny no matter what.
A lot of people are talking about it as if it's self evident which one is better. Or that if I played the sound on a certain device it would be obvious. Can someone state what part of the video is the good part?
It honestly probably would help a lot of people to hear how it's supposed to sound first. It's easy to tell how striking the difference is, but it's probably a lot more obvious how much better it is when you're comparing to a "ground truth".
You might be amused/horrified to know, then, that this is (was?) the top track in Japan for many weeks straight (at least according to Billboard and YouTube.)
Sound on Linux is the one thing that seems to be more confusing 25 years later. I can remember scouring Usenet/mailing lists trying to research which soundblaster card to get for the best experience. When I compare that to wrapping my head around Pipewire+Pulseaudio+Jackd+*effects I feel like I know way less about sound on Linux now. I don't do any professional audio stuff I just want to listen to music on my Linux computers and occasionally play the sound throughout the house. Whenever I start to look into doing it "the right way" it is always overwhelming.
I also know less about sound on Linux now. I don't even know if my system is running Pulseaudio or Pipewire. I don't need to know! I consider this an improvement.
Pipewire and its compatbility programs is all you need. So arch that is pipewire, pipewire-alsa and pipewire-pulse. There's also pipewire-jack if you need jack support.
> These are all techniques that are in wide use in consumer microspeaker systems in tablets and phones, though sadly not common on laptops from most non-Apple brands.
Dell / Realtek / MaxxAudio (not sure who to attribute it to) offers such an implementation with mixed results. Some people go to great lengths to remove it and replace with something that offers a flat response -- personally, I didn't mind the alterations it introduced and the speakers "feel" quieter without it installed.
Our DSP profiles aim to provide a balanced sound, with the features that people expect from high-quality laptop/small-speaker audio. In particular, we aim for:
• A balanced (neutral) tone at moderate listening volumes, with a mostly flat frequency response from a typical listening position
• Reasonably high peak volume with acceptable sound degradation (compression, limiting, etc.)
• "Fake bass" processing to make audible frequencies that cannot be physically reproduced by the speakers, extending the perceived frequency response of the system.
• Equal-loudness volume compensation, so that the sound does not become noticeably tinny as the system master volume is lowered.
[...] Our goal is explicitly not to clone the full/exact macOS audio experience. We consider the macOS speaker DSP processing to be too tryhard.
-----
So I suspect Asahi's implementation will be far more conservative than the systems you're referencing. It's also worth noting Marcan is a musician.
These are very similar things to the features the MaxxAudio control panel offered (and now that I think of it, my ancient Windows 8 tablet had Dolby-badged software on it with a similar feature set):
- Custom response curves for the built-in speaker as well as some brand speakers/headphones (responsible for the "what did you just plug in?" dialog that annoys many users)
- User-adjustable EQ
- Compression, limiter, AVL, "night mode", loudness: I'm lumping these together in one basket as I don't know what components were in use behind the scenes
- Reverb: for cases where you want to listen to music that comes out of a PVC drain pipe of a concert hall's restroom
- Possibly downmixing multi-channel audio for headphone users, but I'm not sure in this one either.
They really go the extra mile, and then another mile on top of it. I guess the only "main" feature remaining essentially all other laptops have is external screen support.
Also, touch id and neural network inferencing acceleration. Presumably, you’d get AI acceleration, but not reasonable battery life on a gaming NVIDIA laptop.
Anyway, once speaker support arrives for the M2’s I’ll try switching back to Linux for my daily driver (almost all my dev work happens in an ARM VM under MacOS as it is…)
As someone who daily drives a Linux M2 MBP: It depends if you can live with some caveats. The main ones are
- No sound from the speakers (unless you have an M1 as can be seen from this post). But headphones work.
- No external screen support
- No Thunderbolt
- No Fingerprint sensor
- No Video decoding/encoding acceleration. But the CPU is strong enough to easily keep up with 4k 60FPS. So you "just" pay for it with shorter battery life.
- No support for some important GPU APIs (Vulkan, OpenCL, newer openGL) which some application you use might need.
The above list is the current state and even a few months from now will probably look different.
I've been using Asahi on the M1 Air for >1 year now for my personal / non-work laptop, and it works decently. With sound & webcam support now enabled, this can now now be used fine as a daily driver. Battery life during use is excellent, up there with the best of any linux laptop, and GPU acceleration is good and getting better every day.
Missing features, so you can decide if those matter to you:
- improved external monitor support
- hardware video decoding - mainly for better battery life, because the CPU is more than fast enough for real-time software decoding. (This is work-in-progress.)
>Seems really terrible engineering to design a laptop where malware can destroy the speakers
It's not something laptop specific: you can damage any pair of plain regular speakers (say hi-fi speakers) by sending them the right (meaning wrong) audio signals to them: burn the voice coil, fry the tweaters, etc. Audio engineers take certain precautions to what they send the speakers.
Laptop speakers have software control of the speakers for protecting them from this, and to allow better performance as long as the components aren't overheating, etc.
All modern hardware can be destroyed by something that gets sufficient permissions to poke hardware registers.
You could for example blow all the efuses in anything with signed firmware versioning - meaning there would be no firmware release that will boot anymore.
You can also typically increase system voltages to cause failure, erase flash so many times it fails in a few minutes, overwrite bootloaders in peripherals so they can't be fixed without a soldering iron, etc.
Properly designed hardware with signed firmware versioning has the bootloader permanently disable the ability to blow efuses until reboot before passing control to the OS, either through hardware or a mandatory hypervisor (and the bootloader itself is trusted and cannot be replaced without either a signature or special physical hardware access).
I hadn't heard of uclamp before, mentioned as a way to save power on the compute intensive DSP work. Found this tweet by Marcan that seems to indicate it's a way to pin the process to e-cores. https://social.treehouse.systems/@marcan/111363323102625920
Huh, is it really true this is the first? I figured this was just being done in hardware in some modern laptops instead of software. At least for basic stuff like EQ, if not compressor/etc. Otherwise, what's with all of the DSP stuff modern Intel laptops need on Linux, what with Sound Open Firmware and whatnot?
(And if not that, I am mildly surprised ChromeOS/Chromebooks don't do much of this either.)
TL;DR various variants of the same technique are covered by different patents, and Apple doing this on application processor avoids some of those patents.
A good example of different approach is laptops branded with "Harman Kardon" speakers - Harman-Kardon has a patent on exactly this but involving separate DSP running transparently to the OS. Similarly there are various other solutions to improve sound quality of small speakers being done, and for some of that modern SoCs are bringing in dedicated DSPs onboard.
Man patents were a mistake. “Run DSP on a separate chip” should not be remotely close to the realm of things which the state creates a legal monopoly for.
Interesting. So, on top of, I presume, whatever DSP you get from the sound chipset/SoC, there could be other layers of DSP throughout the hardware too. That seems like a real pain in the ass, to be honest. (Though personally I'd really prefer something that protects the voice coils from overheating to be in hardware at least, if nothing else.)
(I still do genuinely wonder what's going on inside of SOF on modern Intel laptops, too. That's not separate from the chipset and I don't think it gets tuned for specific laptop acoustics. So what does that do?)
Phoenix APU presentation talk about DSP for dropping processing into input/output of audio (quite probably including things like turning an array of microphones into single source, etc.)
Having recently looked for new laptop, they often have firmware loaded by driver on windows into DSP or sound chain, sometimes even to enable half of the speakers you need to custom load firmware on Linux which apparently includes DSP code that adapts stereo signal for multiple speakers with different parameters.
For the sake of completeness, this problem is not at all endemic to Apple’s M hardware.
Some of the older Thinkpads — W510, T400, and T410, so beloved and praised by Linux enthusiasts, used to suffer from the same problem — their speakers could get destroyed after a few minutes of playing audio. Just wondering if Lenovo’s drivers for Windows 7 included similar safeguards.
Linux had speaker [0] support since longer than I can remember. Reading the headline I was expecting something about software using it to create less low quality output. But it seems it is about modifying the "modern" audio output to work around limitations of laptop speakers.
> This allows the speakers to be driven to much higher peak levels than the worst-case safe volume level, greatly extending their dynamic range.
So software devs are going to drive the speakers past the worst-case safe volume level that was presumably set by hardware engineers? And they are going to do it with software running in a OS that isn't realtime safe?
Anyone else see a problem here?
Also-- does anyone know what Asahi is using to test the safety of what they're doing?
The worst case safe volume levels are levels determined by the speaker manufactures that if you never exceed, you can never harm the hardware (due to overheating, etc).
You can and should exceed those levels to use the hardware as it is intended by the manufacturers however if are doing so, you are now moving from a static system (one set of safe levels) to a dynamic system where the safe levels are determined by a multitude of variables and as such you need to have software or hardware monitoring those variables to keep the system within those safe bounds.
Another person who doesn't understand a damn thing about why the safety daemon is needed or how it works.
If you keep careful track of the audio going through the speakers and the energy in each frequency range, you can figure out exactly what the temperature is at any given moment and make sure it stays under the limit. However, this requires a ton of math.
Alternatively, you can just put a hard cap on the volume, such that no combination of frequencies could ever overheat the speakers. This is safe, but sounds like crap. It's a far, far less nuanced way to do things and results in restricting how hard you can drive the speakers far more than is actually nesisary.
Edit: looks like on the laptops the kernel has access to the actual I/V measurements (feed-back), but on imacs marcan'll have to instead rely on feed-forward looking at the audio signal.
You never overclocked a CPU when you were a youngling?
For example I undervolt my CPU and GPU for lower noise and heat with just 2-3% loss in performance.
everything about asahi feels like it's an apple's product: everywhere you look - it is always "amazing"!
but so far no finally usable implementation exists even for m1 macbooks and they age quickly, and I doubt people will see anything usable in the end (yeah, you might get a fully working Linux on your old dusty m1 when you buy m7, happy?).
so far it is achievements for the sake of achievements
Things take significantly more time without documentation. Try reverse engineering something and you’ll wake up 7 days later with almost no result thinking what the heck were you trying to do in the first place.
so far it is achievements for the sake of achievements
We are people, and we need to feel that our hard work isn’t for nothing. Sharing achievements and getting some praise for it is one way to keep our ambition.
Asahi devs are reading these comments. Don’t shit on their work for no good reason.
So far M systems are pretty similar to each other, which means m2 was much less work than m1. And I suspect m3 will be less work than m2. There's definitely a long delay on the first model, but extrapolating that to 6 next releases doesn't make sense.
> so far it is achievements for the sake of achievements
People are daily driving Asahi today, so that's incorrect.
> but so far no finally usable implementation exists even for m1 macbooks and they age quickly, and I doubt people will see anything usable in the end (yeah, you might get a fully working Linux on your old dusty m1 when you buy m7, happy?).
I'm not sure what you mean, I've been running Asahi on my M1 for about a year now. I have enabled sound (without the safeties, but I'm not listening to anything remotely loud) and the only thing annoying is the lack of microphone (I have to plug headphones when I need a micro).
This seems to be a problem being solved at too low a level of abstraction. It should be able to use the same architecture for performing say a 7.1 to binaural headphone 2-channel output, all by only routing and processing signals. Perhaps this is how it's being solved, but having "speaker" so hardcoded in the project work may not be the case, or seemingly so.
Part of what this is trying to solve requires working with zero abstraction over the underlying hardware: driving the laptop's built-in speakers as hard as possible without literally melting them, which requires not just processing the audio data in realtime, but also accounting for the particular characteristics of each laptop model's several speakers.
All that info can be made available at a higher level. The only reason to do it at a lower one is to reduce surface area where software bugs could destroy the speakers.
> Our implementation, speakersafetyd, monitors feedback signals from the amplifiers, estimates speaker voice coil temperature using a two-stage thermal model, and reduces the hardware speaker volumes when the speakers get too warm. We also have kernel-side interlocks to disable or limit speaker volumes if speakersafetyd is not running or non-responsive.
This is the only part that seems to need to be low-level, anything else could be done at a higher one, generally EQ type settings like 'loudness'.
Existing laptops provide that higher level of abstraction, and audio quality is uniformly garbage.
It’s likely much easier for the open source people to do the work to deal with the underlying physics once, and then port it to all hardware. The laptop models are all essentially the same (they have a few electromagnets, cones and a few sounding boards). Each one has different parameters in their mostly-linear response curves. My guess is that after the first few models work well all the others will rapidly fall into line.
Something similar happened with printers 20 years ago. The open source stack implemented state of the art dithering and font hinting once and ended up producing higher quality output than the commercial windows drivers for the same printers.
Very interesting, but how accurate is that model? It's worth mentioning that even pro audio brands with deeply integrated DSP (e.g. Neumann or Genelec) still use physical thermal sensors. Why? Who knows, maybe to squeeze the last bit of SPL before damage. I suppose that having more than one driver (thiu voice coils with differing sizes and limits) makes things more complicated, too.
I guess/hope amplifier clipping is also accounted for, as the sudden rise in harmonic content can easily damage tweeters (which I think macbooks have?).
This article is a bit bombastic and light on details: "modern audio laptop subsystem", "advanced DSP", "the first desktop Linux platform with integrated advanced speaker DSP", "driving Linux desktop audio forward a couple decades".... while as far as I can tell there are exactly 0 new things described.
> These [DSP profiles] are all techniques that are in wide use in consumer microspeaker systems in tablets and phones, though sadly not common on laptops from most non-Apple brands.
As anyone who has bought a laptop less than 10 years old can attest, practically _all_ laptops ship with "DSP effects for tiny speakers", to varying results. Microsoft has even standarized an API in Windows 10/11 so that you literally can shop for different implementors in the Windows store (e.g. Sonic, B&O, etc.).
> EasyEffects
Article itself mentions previous work on DSP effects...
> we also have the world's first (as far as we know) open source "smart amp" implementation.
Xprot was not open source. Here's a reverse engineered version from much later https://notabug.org/freemangordon/pulseaudio-nokia/src/frema... which turns out to read the ambient/battery temperature rather than coil-specific one. Kind of a similar idea, but more of a really simple precursor to what Asahi did, with no kernel level protection.
I stand corrected, but even the open version happened "much before" this one from Asahi. For kernel-level, there's already quite a bunch of previous work due to Android, so it doesn't really count, either.
I mean a vendor-specific DSP/speakersafetyd/hardware chain being exposed as the onboard speaker device for certain laptops, instead of the raw device.
This has never existed as an OOTB experience. In Apple's case, it's absolutely necessary to avoid blowing up the speakers - hence why they disabled speaker output before the audio chain was done.
It is exactly like that on the Nokia Internet tablets. Speaker protection is literally the role of xprot, which is integrated into pulseaudio -- "necessary to prevent the speakers from blowing out". It even depends on things like the ambient temperature.
I imagine it will be incorporated into other distros soon as a result.