Announcement

Collapse
No announcement yet.

Red Hat / Fedora To Focus On Driving New Linux Video Improvements Around PipeWire

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

  • #41
    Originally posted by Charlie68 View Post

    Those who want professional audio in Linux rely on Jack, but this method is quite complex. Pipewire should fix some usability issues, as well as replace Pulse for everyday use, which should also fix some latency issues.
    If you want professional audio on Linux you need your head examined.

    Comment


    • #42
      Originally posted by quaz0r View Post
      oh shut the front door. WIM TAYMANS ??? nuh uh
      https://en.m.wikipedia.org/wiki/Wim_Taymans

      Comment


      • #43
        Originally posted by sophisticles View Post
        If you want professional audio on Linux you need your head examined.
        https://www.musicianwave.com/best-da...ntu-free-paid/
        Linux systems also report lower latency in audio recording than hardware-equivalent Windows and Mac systems, which is a great advantage when it comes to recording heavy sessions with dozens of inputs.

        As noted here Linux has its issues but it does when it comes to its real-time audio recording stuff linux handle more inputs on equivalent hardware to Windows and Mac. Some cases you need your head examined for using Windows or Mac OS for particular audio work because of the OS issue.

        I would say for audio production at times having Linux will be a god send at other times you will be cursing Linux to hell if its your only OS option.

        sophisticles like it or not there are a lot of people who do use Linux in professional audio work. Of course for those starting out getting rid of the pulseaudio/jackaudio fight over what one should be in charge of audio devices will be a good thing.

        Comment


        • #44
          Originally posted by Zoll View Post
          I'm on pulseaudio (like most Linux users) and I don't recall experiencing any issues. What problems were so common that it warranted Pipewire development as a replacement?
          From what I read a lot of early pulseaudio bugs were due to canonical having misconfigured it in Ubuntu. It also exposed a lot of bugs in underlying drivers using functionalit that hadnt been used as much at that stage.

          Pipewire mostly has a different focus - Pulseaudio was designed before desktop containerisation became a thing. Having to retro-fit it would have been a big challenge.

          Pipewire is standing the shoulders of giants though - without all the work of pulseaudio and the fixing of bugs it exposed in alsa drivers

          Comment


          • #45
            Originally posted by david-nk View Post
            a system component has reached a stable status
            in biology stable means dead

            Comment


            • #46
              Originally posted by doomie View Post
              I'm probably wrong.
              that's a safe bet

              Comment


              • #47
                Originally posted by brad0 View Post
                Glad I dont use this crap.
                browser or kernel?

                Comment


                • #48
                  Originally posted by Zoll View Post
                  What problems were so common that it warranted Pipewire development as a replacement?
                  no video support? mutual exclusion with jack? not designed for containers?

                  Comment


                  • #49
                    Originally posted by Zoll View Post
                    I'm on pulseaudio (like most Linux users) and I don't recall experiencing any issues. What problems were so common that it warranted Pipewire development as a replacement?
                    You have pal666 list
                    no video support? mutual exclusion with jack? not designed for containers?
                    This is very undetails. Video support is that pipewire can use the audio sync interface in alignment with the video sync interfaces making it simpler to in fact get video output synced with audio.

                    Containers with pipewire you can have jack applications in flatpak and equal and have them authorised to access the host. Jackaudio does not support containers. Pulseaudio requires a wrapper to support containers as well. A container application that only wants audio output should not be allowed to capture audio and things like this. This is another area of pipewire increased meta data space and the fact it can process a permission system. Pipewire is more feature rich in most cases there is one exception.

                    One of the big ones is a feature pipewire intentionally does not have as mentioned eariler.
                    https://www.phoronix.com/forums/foru...10#post1282410

                    Pipewire lacks buffer rewinding. This means once audio is sent to output there is no changing your mind at all. This sounds like a disavantage until you wake up 99% of the cause of pulseaudio generating by it self a audio hiss/crackle requiring you to kill/restart pulseaudio to fix is in fact the rewind feature gone off the rails. Due to the way human hearing works most time will not at all notice a buffer of audio missing. But human will absolutely notice if the buffer rewind code screws up. And there are many ways buffer rewinding can screw up resulting buffer rewind that is run over play point of the output device yes this causes a messed up audio being individual crackles, hisses, pops and if it looping screw up constant crackles, hisses and pops yes those three things end users don't particularly like.

                    Comment


                    • #50
                      Originally posted by oiaohm View Post
                      https://www.musicianwave.com/best-da...ntu-free-paid/
                      Linux systems also report lower latency in audio recording than hardware-equivalent Windows and Mac systems, which is a great advantage when it comes to recording heavy sessions with dozens of inputs.
                      What does it mean that "Linux systems also report lower latency in audio recording"? Who are they reporting to and in what fashion?

                      The article also fails to mention that Linux can only really be used for serious DAW if you swap out the default kernel and instead use a low latency or real time kernel. Comparing such a modified Linux based distro against a default Windows or OSX setup is dishonest.

                      Comment

                      Working...
                      X