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 ( https://lore.kernel.org/lkml/[email protected]/ ).

  • setVeryLoud(true);@lemmy.ca
    4·
    4 hours ago

    Oh it’s already easy. You start asking the submitter to explain the code. Sometimes it’s just visually obvious, too.

    I’ve always had the opinion of it not being slop if you:

    1. Take ownership and fully understand the code
    2. Make it look like a human wrote it, in other words, scrutinize, re-factor and re-format the code for legibility, performance and maintainability before submitting your patch

    This effectively forces you to do research to properly understand how your patch is implemented and puts you through the mental exercise of cleaning up the code. It also more often than not mostly replaces the code the LLM generated anyway, making it yours.

    I say all this as someone who turns around a lot of PRs at work for being slop. Come back to me when you can take ownership of your git blame.