New in Fedora Asahi Remix

Want to find out what’s new in Fedora Asahi Remix? Check out our recap of everything we’ve been up to!


Thanks for all of your work on this project! I’m greatly thankful for it!

1 Like

I’d love to learn more about how to use utilization clamping, as it sounds like a godsent for laptops! Would it make any kind of difference in regular x86 laptops without BIG-LITTLE cores though?

Also, would Bankstown work on any laptop that has a dedicated subwoofer? I have a particular problematic model from DELL that on Windows needed their proprietary Waves Maxx Audio software to sound even half decent, but on Linux it doesn’t sound half-bad. This seems like it could help make it sound at least a little better.

The gist of util clamping is that we basically limit the scheduler’s internal representation of “performance requirements” to a predetermined range of values to force it to behave a certain way. The benefit is twofold here: force the CPU the task is running on into an operating point that we want, and force the scheduler to put the task on a particular type of core.

You still get the first benefit on homogeneous systems and this trick has been used forever on Android. I would really like to see it being used more in the desktop world now that it’s enabled in the Fedora kernel!

Bankstown is just an LV2 plugin implementing the missing fundamental effect. It will work in any LV2 plugin host, including DAWs. Additionally we designed our DSP loading mechanism to be as general as possible, so using asahi-audio as a base you can craft custom DSP profiles for any device you want.

With one minor caveat, that the device matching is limited to what PipeWire can do. For Apple we control the kernel driver and we can make sure it uses unique ALSA card ID names we can match against. Other platforms may need to yak shave figuring out how to match specific device models (e.g. PipeWire might need a DMI match feature too or something).

So this looks like over the general user customization tool and more into package maintainer responsibility, right? I’d love to see that being used more in the future!

Just making sure that I understood correctly, but in this case any user could just get bankstown from the repo and use it in something like Easy Effects like some people have been doing for a similar effect to Dolby Atmos?

It actually has to be done by the developer as it requires implementing some syscalls. The best-practice way to do this is have the application track some performance metric and dynamically set its uclamp windows based on the performance level it needs. This lets the application adapt to different systems and its own changing resource intensity.


That’s great to hear!

Not sure if they already had the chance to read it or if this will ever come in handy for the team, but @mpearson, both speakersafetydand Bankstown could be great for future Thinkpad lines, just like thermald.