linux VS asahi-audio

You're missing on a lot of things Rust (or any language with non-toy types) can provide. Lock ordering, better accessible complex structures, enforcement of enumerated options, rich description of APIs, and many others. Atomic values are usable transparently https://github.com/AsahiLinux/linux/blob/97c628055904a7f2ef1... and multithreaded reference counting is easily enforced https://github.com/AsahiLinux/linux/blob/bd0a1a7d465fcb60685... also issues like type confusion https://www.vicarius.io/vsociety/posts/a-type-confusion-bug-... are less likely if you can easily use tagged unions checked by the compiler.

From the gpu issue tracker[0]:

> For a bit of context -- Google Maps loads images to the GPU at.. inopportune times. While games would typically load their images during a load screen (so slow image loading just means longer loading screens), Google Maps loads when scrolling around I think (so slow image loading means the whole map stutters). I don't think there's a fundamental driver bug we can fix here, but we can make image loading a lot faster which makes the symptoms go away.

[0]: https://github.com/AsahiLinux/linux/issues/72#issuecomment-1...

> Is this mostly just a thing to get more young people interested in kernel development...allowing them to start out in less important areas and in a language they are passionate about?

Not likely. At the moment you need to do extra work to get Rust working well. It's not exactly beginner friendly and doing work in the kernel, you'll need to dig into C anyway.

> Or is this a serious proposal about the future of operating systems and other low level infrastructure code?

Serious code already exists, so... Yes?

> Do you just program everything in unsafe mode? What about runtimes?

Why would you? You need that only when interfacing with something that can't hold the Rust compiler assumptions. See for example https://github.com/AsahiLinux/linux/blob/gpu/rebase-6.4/driv...

The few places that need direct access / unsafe are almost all single-line areas with an explanation.

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 am using Asahi Linux and the GPU driver works great, it even supports OpenGL 3.1 (https://asahilinux.org/2023/06/opengl-3-1-on-asahi-linux/). Definitely not alpha, I would say it's close to a "release candidate". Many bugs got resolved, nothing much left (besides newer OpenGL and Vulkan of course, but current state is very stable): https://github.com/AsahiLinux/linux/issues/72

There aren't really any non-trivial mainline modules, since the Rust support is so new. There's the non-mainline Asahi M1 GPU driver though! It will eventually be mainlined, but IIRC some more Rust support code needs to be mainlined first.

https://github.com/AsahiLinux/linux/tree/asahi/drivers/gpu/d...

You can follow the progress here: https://github.com/AsahiLinux/linux/issues/91

This project seems to be progressing the audio, activity from last month.

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

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.

Is this then the repo that needs to be finished up https://github.com/chadmed/asahi-audio ? If that is the case, do you (or anyone else in the thread) know what is left for the quality to meet the standard of Asahi?

Trying to follow the guide here - https://github.com/chadmed/asahi-audio and everything seemed painless until I got to the devicetree part, and it has stumped me. Being a regular Arch user for more than 4 years and this is either 1) So easy everyone can do it and I just am not understanding 2) More difficult than anyone is willing to provide guidance on.