3 ms·

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 mo

by argsnd 3y ago

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.

ishvanl 3y ago
Do you have a source on the MacBook audio thing? That's something I'd very much like to have a look at.
- lloeki 3y ago
  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/ https://asahilinux.org/2022/11/november-2022-report/
lloeki 3y ago
I am aware of that, that's why I mentioned it could be an ALSA plugin. From https://github.com/chadmed/asahi-audio 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.
- argsnd 3y ago
  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/ https://asahilinux.org/2022/11/november-2022-report/
  - wtallis 3y ago
    > 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?
  - dezgeg 3y ago
    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).

by argsnd 3y ago

ishvanl 3y ago

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

lloeki 3y ago
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/ https://asahilinux.org/2022/11/november-2022-report/

lloeki 3y ago

I am aware of that, that's why I mentioned it could be an ALSA plugin. From https://github.com/chadmed/asahi-audio 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.

argsnd 3y ago
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/ https://asahilinux.org/2022/11/november-2022-report/
- wtallis 3y ago
  > 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?
- dezgeg 3y ago
  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).