Comment by lloeki | Hacker News Reader

Comment by lloeki | Hacker News Reader

> We aren't going to stop you from running ... no sound server

> your speakers sound terrible and tinny or don't even work at all by default (once we ship that)

So this sounds completely unrelated to Xorg vs Wayland. Can someone care to explain?

I do prefer Xorg currently but I can think I can live with Wayland (I tried a bunch of times before, some things I found better than Xorg, but others were blockers, although they ought to be resolved someday I guess). Both live in userland though.

Comparatively, this sounds quite surprising. Is the use of a sound server like pulseaudio or pipewire basically mandated to safely handle the audio hardware? Why should I need those?

I'm aware of the design of these Macs audio that can physically destroy speakers if not driven correctly, and I know it's being worked on, but it seems to imply the safety features are handled at the userland (pipewire I guess?) level instead of the kernel/ALSA level (which IMHO is what should be done for something that can irremediably destroy hardware).

Thus, while I can understand that it wound be quicker to develop and validate such protections in userland, but ultimately I believe the end goal would be to have safe audio hardware support right in the mainline kernel, or at the very least as an ALSA plugin (which would be equivalent to mesa for graphics support)

EDIT: seems like it's pipewire: https://github.com/chadmed/asahi-audio

I believe it is essentially to replicate macOS behaviour. Part of the reason MacBooks have great audio is because instead of setting a hard volume limit they model the coil temperatures and modify limits on the fly. That’s something which is too complex to do in kernel.

Do you have a source on the MacBook audio thing? That's something I'd very much like to have a look at.

It was mentioned in one of their reports, and IIRC discussed here and there on some twitter or fediverse thing.

https://asahilinux.org/2022/11/november-2022-report/

I am aware of that, that's why I mentioned it could be an ALSA plugin.

From https://github.com/chadmed/asahi-audio

> ASoC exposes the speaker array as six independent drivers - two woofers and a tweeter each for Left and Right. We want userspace to see this as a standard stereo speaker pair. The configuration fragment shipped in this package sets up a virtual sink that takes a stereo input and routes it appropriately to each driver.

> We then run into another issue - the speakers sound awful. Turns out Macs aren't magic, they sound good because Apple invest a lot of engineering effort into DSP. Apple actually handle this with odd bespoke Core Audio plugins. We use PipeWire's convolver plugin to apply impulse responses to each driver, which effectively EQs the output signals.

> The kernel driver currently makes no effort to diminish your ability to destroy your machine through misconfigured settings in userspace

This is what I find quite unacceptable from a design PoV, this kind of safety should be as close to the kernel as possible.

It can't be though. The kernel itself can't include anything requiring floating point maths, so it needs to be able to permit userspace to unlock any restrictions in order for those calculations to happen there. And Asahi is intentionally being designed for the modern systemd/wayland/pipewire stack so they're not going to work on ALSA plugins since pipewire replaces that part of the stack.

The Asahi team do say there will be a basic level of safety implemented in the kernel like this:

> some kind of “safety watchdog interlock” with the kernel that only enables higher volume limits when the daemon is active and running

https://asahilinux.org/2022/11/november-2022-report/

> The kernel itself can't include anything requiring floating point maths,

This sounds like a limitation derived from ancient architectures and platforms. What's the barrier to allowing FP in kernel modules for platforms that are guaranteed to have FP support? Is it too much work for the kernel to save and restore FP registers and modes?

This is wrong; using floating point (or rather, the vector register set like XMM) is used for example for cryptography. It does have extra cost though (as kernel doesn't normally save FPU/vector regs).

Reply on news.ycombinator.com