Announcement

Collapse
No announcement yet.

The Story Of PipeWire & How It's Getting Ready To Handle Linux Audio + Video

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

  • #51
    I've been running the guitarix effects stack on F34 since a little after the beta came out. It was easy to select the inputs from my guitar adapter and it's been working quite well. The latency is quite acceptable and the output sound is pretty well in sync with my guitar playing.

    Comment


    • #52
      Originally posted by sandy8925 View Post

      Replaced what that was already working? ALSA is a kernel interface, only one application can use it at a time. So as soon as one app takes exclusive control of a device through ALSA, no other app is able to play sound through it...........

      ​​​​​Pulseaudio is great and amazing. Implementation may have had problems, but the concept was needed.
      PulseAudio was replaced. Anywau, doesn't matter. Seems others using PipeWire on Manjaro aren't having tissues, so I'm glad it's working.

      And I've probably even inadvertantly accepted the PipeWire package over PA "multiple option/Select option 1/2/3" Manjaro usually uses in their pacman updates, so double poops for me 😁
      Hi

      Comment


      • #53
        Originally posted by sandy8925 View Post

        Replaced what that was already working? ALSA is a kernel interface, only one application can use it at a time. So as soon as one app takes exclusive control of a device through ALSA, no other app is able to play sound through it...........
        That wasn't even true when pulseaudio was released. You could have multiple applications connected at once. It was true perhaps 20 years ago.

        Comment


        • #54
          Originally posted by WalterCool View Post

          It's same as Pulseaudio mode. At least Rosegarden works LOT better on Pulseaudio mode than Jack mode under pipewire. That means lot of latency, which is not good.
          Which version of pipewire? Did someone manage to get consistent performance with a 32 buffer?
          ## VGA ##
          AMD: X1950XTX, HD3870, HD5870
          Intel: GMA45, HD3000 (Core i5 2500K)

          Comment


          • #55
            Originally posted by carewolf View Post
            That wasn't even true when pulseaudio was released. You could have multiple applications connected at once. It was true perhaps 20 years ago.
            That was only true if:
            - Either you had put cash up for a fancy audio card that did have the "(HWmix)" tag in the alsa project's support matrix (I used to have second hand Audigy cards back then).
            - Or you did run another sound mixer. Except that the only mainstream back then was running DMix which is running as a kernel driver (so all the audio processing is happening in-kernel) and has a fixed latency (not this adaptive latency thing that pulse audio developed).

            There were a couple of sound mixing daemons before (KDE application has Artsd, Gnome application had esound), but they weren't widely supported outside their respective desktop environment.

            Adobe Flash was an example of something that only exclusively supported ALSA and would constantly grab your audio. In-kernel alsa dmix was the only solution before pulseaudio.

            Originally posted by stiiixy View Post
            I DO know that a recent Manjaro update completetly fucked my audio, yet thankfully a simple PulseAudio reinstall fixed that.
            Was hit by the same, Just takes literally a few seconds to find out the culprit:...

            Originally posted by Alexmitter View Post
            Likely its just Manjaros horrible config work that broke your sound. Its not the first package that completely broke on manjaro due to the more then incompetent developers behind messing the config up.
            ...Comes from upstream Arch, it's due to the session manager (the thing that maps hardware into pipewire) not being started as part as the main daemon anymore, but launched as a separate service.

            Originally posted by Alexmitter View Post
            Pipewire is not any less focused on the desktop as Pulseaudio.
            Pipewire also tries to handle a lot of modern use cases that Pulseaudio doesn't handle, mostly in the automotive industry, but not only:

            - routing between multiple machines (the embed device playing the audio (e.g.: infotainment center) isn't necessarily the same producing it (an alarm) in car, unlike on a single seat computer)
            the features exist in pulseaudio but aren't as systematically deployed as with pipewire.

            - having different stream types with different priorities (an alarm should take precedence over the radio, but not necessarily over voice communications), and potentially different audiorouting.
            (the feature exist in KDE's Phonon, but aren't much used outside of KDE's ecosystem).

            - hardware audio routes: in a desktop, everything goes through the main OS and goes through the central mixing daemon (be it Pulseaudio now, or be it dmix 15 years ago).
            In a smartphone, the modem is able to process audio and send it to the audiocodec. Under some circumstance it could even route the audio over bluetooth. All this while the main OS is sleeping. Pipewire's approach of considereing separate devices/CPUs/codecs makes this much easier, which is a big power-saving feature.
            (Though eons ago, ISA and older PCI cards did have direct input/output whose volume could be set using the level mixer. Thus the audio from the analog modem could be routed over the sound-card to make a voice call without any intervention of the OS).

            - giant piles of I/O.
            Pulseaudio is strongly designed with desktops and laptops in mind. Which tend to only have a couple of multi-purpose jacks. So the audio card can only function in a couple of different mutually-exclusive modes (either run the card in 6.1 and use 3 jacks for multi-channel output, or do stereo duplex by repurposing the jacks a mic-in/aux-in. Digital SPDIF is done by mapping a different output to the stereo-output jack). This entirely makes sense for what 99% of users will have on their laptops.
            But this doesn't really makes sense on higher-end audio cards that have a much wider selection of input/output (again, Audigy with the expansion box: Has dedicate 7.1 output, and dedicated multiple analog inputs and dedicated digital duplex, both TOS-Link and SPDIF. All accessible at the same time)
            And this makes even less sense on professional audio interface that tend to have a huge pile of I/O ports, each with its own dedicated DAC and ADC (e.g.: 16 inputs, 16 output), that all needs to be routed independently (different instruments recorded from different inputs) instead of as single multichannel output.
            Jack does this nicely, and Pipewire stives to bring this into a pulseaudio-like simple interface.

            Comment


            • #56
              Jack is really the best.

              It's difficult to use because programs that want to use it have to be compiled with it and it's difficult to configure because the end user tools do not receive a lot of love and attention. Everyone is too busy working on these (useless) audio systems like Pulse.

              I don't have a lot of hope Pipewire will be anything good. Just fix jack, stop throwing new stuff at the wall.

              No musician ever will use Linux for anything till this is fixed.

              Automotive is the bane of Linux, Ford needs to go make their own OS the stuff they needs (and thus do to Linux) is wrong and just not appropriate.. the OS can't be all things to all people.
              Last edited by k1e0x; 17 May 2021, 03:17 PM.

              Comment


              • #57
                Originally posted by k1e0x View Post
                the OS can't be all things to all people.
                Funny. Isn't refusing to just roll over and accept that the reason the Linux kernel runs on everything from smartphones to supercomputers?

                Comment


                • #58
                  Originally posted by pal666 View Post
                  i was already replying to something similar in other article. wayland replaces protocol, you have to rewrite all apps. pipewire replaces only implementation, it keeps pa and jack protocols intact, so you don't have to rewrite apps(modulo bugs)
                  well, thats kind of the problem, how every single DE has to write their own wayland implementation unlike on Xorg, btw it doesnt help at all that the protocol itself is broken by design...

                  Comment


                  • #59
                    Originally posted by k1e0x View Post
                    I don't have a lot of hope Pipewire will be anything good. Just fix jack, stop throwing new stuff at the wall.

                    No musician ever will use Linux for anything till this is fixed.
                    I think musicians are already quite pleased with Pipewire. The next thing to focus on would be building the higher levels (GUI software) of the free pro audio software stack.

                    Comment


                    • #60
                      Originally posted by davidbepo View Post
                      well, thats kind of the problem, how every single DE has to write their own wayland implementation unlike on Xorg
                      on xorg every de had to write its window manager which is similar in scope/difficulty to wayland compositor
                      Originally posted by davidbepo View Post
                      , btw it doesnt help at all that the protocol itself is broken by design...
                      you aren't smart enough to judge design of wayland protocol

                      Comment

                      Working...
                      X