No announcement yet.

SoundWire Subsystem Revised For The Linux Kernel

  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by starshipeleven View Post
    No offence, but here the issue is on your side. The title isn't clickbaity and the article states "SoundWire is a low-power, two-pin bus that's been around since 2014 for supporting multiple audio streams and embedded control/commands".

    If you misread that it is your own problem. Others didn't understand the technical side, but they asked for explanations, they didn't jump to conclusions.
    Regardless of the article, the title may be misleading and someone might think SoundWire is an ALSA replacement. And I'm aware many people would love this, removing the necessity of layers like PulseAudio and Jack/Jack2 (two versions, another mess).

    But I would also love that all Linux-rt patches get merged upstream, along with some other patches/forks focused on security too. uCLinux would be a great candidate as most of that stuff is forked from upstream.

    Why do I mention Linux-rt/Linux-RT? Because it's relevant to sound, specially on audio workstations where low latency is quite important. Windows has ASIO, macOS has it's own stuff for that too (sorry, I don't remember the name... but maybe it ends with Kit or it's... CoreAudio?). There are rt-like prioritization in certain subsystems, but that's not enough in my opinion.

    And I also consider Cgroup/Cgroup2 is both underused and underrated. I still wonder why titanic apps can freeze the rest of the system these days when having theoretically more than enough subsystems to avoid that, I suffer that when I open too many tabs on Mozilla Firefox or use mammoths like Eclipse or other Java apps.

    This is more off-topic:

    I consider Linux kernel still lacks certain flexibility to become part of a full desktop system, plus excessive layers to patch issues from the core implementation. One of them are sound daemons/managers of whatever you want to name them.

    Even more offtopic than before:

    I think there's lots more, like:
    - Not a full PackageKit implementations of different package manangers.
    - The one-programming-language=one-package-manager mess.
    - The Snappy/AppImage/FlatPak/Zero Install aberration: Despite that Linus uses AppImage for his diving app, I disagree. I think the solution should be done in a reverse way, so PackageKit should evolve to become a framework to generate native packages instead.
    - The console terminal: Use of obsolete layers like TTYs and such. Despite the functionally interesting layers like GNU Screen/Tmux/Tmate and MoSH are something good to have, I think that should be reimplemented in a more clean and robust way. Notty concept has some nice ideas, for example. It's a shame KMSCon seems a dead project, these days I used Terminology in console and the experience is better than a bare console most of the time. I also would preferred that libtsm become further developed and widely deployed instead using toolkit-dependent solutions too.
    - Remote connectivity (file sharing, network fs, remote desktop/terminal, etc): SSH is nice, but at same time is becoming like another obsolete thing that negates to die, like a dinosaur in our age. It can also may be messy for certain stuff like X redirection. I wonder why 9P (a very underrated concept of Plan9, even more interesting than UTF-8 in my opinion) is used in Virtual Machines only, instead getting it expanded and improve it to become a full blown protocol to share anything, able to even replace NFS and Samba but also serve to redirect other I/O (video, audio, HID, etc).
    - Too many "standard" frameworks not being really agnostic: They may use GLib (I name it "Gnome Lib", Gvfs/GIO, KIO or any other library that impose certain concepts from certain communities (generally desktop ones). The real success of stuff like FFMpeg (LibAV fork is another topic) is that is really portable and has a very low need of exclusive dependencies. I think this is one of the reasons of why stuff like Libpurple/Telepahy/Empathy fail to become relevant and widely adopted and deployed by developers of communication (video and/or audio and/or text (formatted or not), file sharing, stickers, photo/album/video sharing and whatever) software.