Linux 7.4 Sound Changes Merged: "The AI Flood Continues"
Linux sound subsystem maintainer Takashi Iwai of SUSE began the Linux 7.4 sound pull request by noting that "the AI flood continues" with there continuing to be a lot of new patches coming as a result of AI/LLM agents devising patches as well as uncovering new kernel bugs.
Takashi went on to explain that it was another busy cycle with changes in the sound subsystem from lots of core code hardening to new platforms and codecs as well. The core ALSA code has been hardened against some race conditions, there's a buffer leak fix in the compression offload code, race fixes in the JACK code, and other race conditions and more typical C bug fixes. The OSS sequencer emulation code has also been marked as deprecated for Linux 7.4.
On the hardware side, the Linux 7.4 sound updates include support for compressed audio playback on SOF IPC4 with Intel Tigerlake and newer. There is also AMD ACP 7.0/7.F sound IP support with SoundWire and the PDM controller. The new AMD ACP 7.0/7.F IP appears for upcoming Ryzen Zen 6 platforms.
There are also quirks for many different Intel/AMD laptops from the likes of Lenovo, ASUS, HP, AAcer, HONOR, MSI, and others.
New codec drivers are for the ESS ES9039Q2M, Nuvoton NAU83G60 amplifier, Senary SN624x SoundWire SDCA codec.
Also new is the Qualcomm QAIF driver for their Shikra platform.
More details on the many sound changes for Linux 7.4 via this pull ( lore.kernel.org/lkml/87ecdgc24… ).
Linux 7.4 Sound Changes Merged: "The AI Flood Continues"
Linux sound subsystem maintainer Takashi Iwai of SUSE began the Linux 7.4 sound pull request by noting that 'the AI flood continues' with there continuing to be a lot of new patches coming as a result of AI/LLM agents devising patches as well as unco…www.phoronix.com
thingsiplay
in reply to SocialistVibes01 • • •HelloRoot
in reply to thingsiplay • • •Only if it is packaged like python on arch.
I never had so many problems with anything else on linux but pip, npm, and cargo.
thingsiplay
in reply to HelloRoot • • •I don't think that a package manager and cargo should be included by default, if Rust compiler and the standard library was installed. One can use the compiler
rustcwithout Cargo. Also there are works to create a new independent compiler for the GCC framework, but that takes forever it seems.That would off course mean that many projects cannot be compiled without a package manager and all their dependencies. But it would make it like Python (and C compilers) be possible to compile individual files. That could make it to a standard way of distributing simple projects which does not require any external libraries at all. This could encourage such projects too, which isn't a bad thing at all to me.
And it just occurred to me that probably some Rust libraries could be installed as a separate Archlinux package too, so you don't need external package manager. Haskell in example does that, and off course Python packages.
HelloRoot
in reply to thingsiplay • • •Ephera
in reply to thingsiplay • • •Firefox and Python's cryptography toolchain have a build dependency on Rust, which are two packages that virtually all Linux distributions have packaged. So, some version of the Rust compiler is going to be available on virtually all Linux distributions.
There's no real reason to have the Rust compiler installed on non-dev systems, as you don't need it for running Rust programs (although I kind of assume you know this).
But yeah, it seems to be possible to dynamically link the standard library into Rust programs, so Linux distros could try to share that between them, and then it would effectively be installed by default.
thingsiplay
in reply to Ephera • • •You don't need to be a developer in order to compile little programs. Like in C it is totally normal to do so, without being a programmer. Just use a make command on a Github project and install it manually. I would put Rust at the same level as C, so yes, most people wouldn't have it installed or need it. But the compile
rustcshould be packaged by all distributions and it should be part of a meta package for basic development tools (also used by non developers).In a way that any program could assume everyone on Linux is able to compile with a basic Makefile, like we do this with C in example (if compiler tools are installed). I didn't even think about dynamically linked standard library.
urushitan 漆たん
in reply to thingsiplay • • •thingsiplay
in reply to urushitan 漆たん • • •rustcwhich does not need the entire toolchain like cargo and eco system. It can be used like Python and C with standard libraries only and adding libraries manually without package manager.Ephera
in reply to SocialistVibes01 • • •MonkderVierte
in reply to SocialistVibes01 • • •Ephera
in reply to MonkderVierte • • •This is about the official systemd repository. They use a mono-repo-approach, where all the official components are in one repository and use the same build system, so adding a second language into that is a bigger hurdle.
If you develop a third-party tool that somehow hooks into systemd, then you can use whatever language you want.
MonkderVierte
in reply to Ephera • • •Ah, makes sense, thanks!
While i don't think that a monorepo with no scope guard rails is a good idea.
thingsiplay
in reply to MonkderVierte • • •