Announcement

Collapse
No announcement yet.

Linux 5.16 Aims For Better USB Low-Latency Audio Playback

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Linux 5.16 Aims For Better USB Low-Latency Audio Playback

    Phoronix: Linux 5.16 Aims For Better USB Low-Latency Audio Playback

    The Linux kernel is trying again to enhance the low-latency playback mode of its USB audio driver...

    https://www.phoronix.com/scan.php?pa...6-USB-Audio-LL

  • #2
    This sounds fantastic, what with how USB audio interfaces and DACs have pretty much taken over the entry-level "at least it's not motherboard sound" market.

    Comment


    • #3
      Please make ALSA a lot less shitty and a true OSS competitor in embedded space, requiring less layering in userspace (PulseAudio, PipeWire, Jack, Jack2...).

      Comment


      • #4
        Originally posted by timofonic View Post
        Please make ALSA a lot less shitty and a true OSS competitor in embedded space, requiring less layering in userspace (PulseAudio, PipeWire, Jack, Jack2...).
        that is not an ALSA problem, but an generic Linux desktop user-space stack choice. ALSA as it worked well for 20+ years without all this and still does. But people want PA or PW.

        Comment


        • #5
          Originally posted by timofonic View Post
          Please make ALSA a lot less shitty and a true OSS competitor in embedded space, requiring less layering in userspace (PulseAudio, PipeWire, Jack, Jack2...).
          Are you aware of the history of ALSA and how that was already tried? It's not the kernel's responsibility to remember what to do with your headset when you plug it in, that's something better solved in user space. Or if you want more kernel vulnerabilities, stuffing userspace features into the kernel is how you make them. Hmm, this vaguely reminds me of the graphics layer that was embedded in Windows 9x kernel and was the source of non-existent stability and 0-day exploits.

          As time goes on, ALSA will become more and more thin as it properly settles as a driver layer for great software like PIpeWire to utilize.

          Comment


          • #6
            Latency has been good for the past decade or so, what I still dislike with audio are clicks and pops on start of every song, presumably by opening some stream or something like that. Different devices do it differently, one firewire dac takes seconds to start playing (and makes seeking impossible due to this), one very new usb dac has only tiny pops, while one older one has none and is smooth at seeking too. Don't know enough about inner workings of this code and these devices to really understand where the difference is coming from.

            Comment


            • #7
              Originally posted by damentz View Post
              Hmm, this vaguely reminds me of the graphics layer that was embedded in Windows 9x kernel and was the source of non-existent stability and 0-day exploits.
              If you mean GDI, then it was present there since the beginning of Windows with only briefly being put outside in NT 3.x. The next NT version put it back into the kernel where it stayed to this day. 9x's stability problems were only partially related to GDI being in the kernel.
              But you're correct about the security implications - there's rarely a monthly patch day that doesn't include something from GDI and/or fonts (which are also handled in kernel mode)

              Comment


              • #8
                Originally posted by timofonic View Post
                Please make ALSA a lot less shitty and a true OSS competitor in embedded space, requiring less layering in userspace (PulseAudio, PipeWire, Jack, Jack2...).
                https://www.alsa-project.org/wiki/SALSA-Library

                Also

                https://github.com/tinyalsa/tinyalsa

                which PipeWire apparently uses.
                Also see this presentation about using PipeWire in embedded space:

                https://embedded-recipes.org/2019/ta...ed-multimedia/

                And

                https://www.collabora.com/news-and-b...dia-landscape/

                ​​​​​​Basically PipeWire and therefore Alsa is already used in the embedded space (Automotive Grade Linux).
                ​​​​
                No one cares for OSS.
                So no need to replace Alsa for interfacing the sound drivers in the kernel. It works fine. It's the user space sound stack that needs to evolve.
                Last edited by tomas; 03 October 2021, 03:51 PM.

                Comment


                • #9
                  Lower latency is always a good thing, but USB is a poor tool for delivering low latency or real-time audio/video streams. Firewire was inherently isochronous, the primary reason the A/V industry settled on it way back when. Plus it was way faster than USB2, something like 2.5x the throughput in real world usage. I remember getting a consistent 78 MB/s when reading from external FW hard drives, while USB2 struggled to break 30 MB/s. Disclaimer: I'm not that familiar with how USB3 differs vs. USB2, so perhaps there is some magic mojo that makes it more suitable for A/V tasks.

                  Comment


                  • #10
                    Let's see how stability is, e.g. if you have 3 identical USB sound cards, USB is also under heavy load from video (webcam + mic), add or remove devices while still in use.

                    Comment

                    Working...
                    X