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

  • #51
    Originally posted by sophisticles View Post
    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.
    That article is right for the current state. What you said was true about 5 years back. If you have not swap out the default kernel you are still ahead using Linux over a Windows or OSX setup. Its due to how much of the real-time tree of Linux is merged mainline these days.

    https://jackaudio.org/faq/realtime_v...me_kernel.html

    You want to run JACK with very low latency settings that require realtime performance that can only be achieved with an RT kernel
    Your hardware configuration triggers poor latency behaviour which might be improved with an RT kernel
    There are only 2 cases to use a real-time kernel of Linux for audio work these days. Yes hardware issues is highest reason. Very low latency setting is past what default Linux kernel will give you and that Linux default kernel is ahead of Windows or OSX setup already.

    The direction on usage of a realtime kernel changed about 4 years back with jack audio that you need to think twice about using it. Hard realtime that the RT kernels of Linux can give you can cause more problems than what they are worth in fact. The Linux kernel soft realtime has been improving leaps and bounds as the real-time tree patches have merged mainline.

    sophisticles basically stock Linux kernel beats windows and mac os in that department these days. Then real-time patched versions of Linux can slightly beat Linux. Real-time scheduler is include in the default Linux kernels for over 5 years and over the past 5 years more and more of the real-time tree is merging into the mainline kernel causing quite a marked change in position.

    https://www.phoronix.com/scan.php?pa...g-In-Linux-515 yes even more RT patches merged with 5.15. This has progressive result in less and less cases you should use a specialist real-time kernel with Linux. And this has also lead to a progressively growing gap in default functionality for audio between Linux and other OS options in Linux favour of course.

    Part of the reason for the pipewire work is due to the fact you don't need specialist kernel in 99.9% for audio work any more with Linux. So the problem between pulseaudio and jack had to be solved.
    Last edited by oiaohm; 03 October 2021, 03:27 AM.

    Comment


    • #52
      Originally posted by sophisticles View Post

      If you want professional audio on Linux you need your head examined.
      You don't know what you're talking about ...

      I have a professional musician friend who uses the vanilla kernel and makes professional audio, today it is no longer necessary in the vast majority of cases to use the low latency kernel, the difference is then the hardware in use and its compatibility with the linux kernel .
      Last edited by Charlie68; 04 October 2021, 04:49 AM.

      Comment


      • #53
        Originally posted by oiaohm View Post

        Yes and no.
        https://github.com/wwmm/easyeffects

        People were attempting to add audio effects like noise removal with pulseeffects before pipewire. So not having routing graphs and DSP effects in pulseaudio was leading to some horrible work around as well.
        Horrible workarounds? Do you even realize how pulseaudio works? The sink/source model is pretty easy to comprehend as well as the PA LADSPA plugins. The same plugins also work for ALSA. First, learn how PA and ALSA differ here. Then we can discuss what this horrible workaround is that you're referring to. The main difference between PW and PA here is PW supports lower latency and has a bit different behavior wrt rewinds and buffers.

        See the yes and no. Yes it is slightly more complex but over all its not more complex because you don't have horrible hackly solutions for like pulseeffects was to add in functionality. Pipewire might be just at the ideal sweet spot for a audio sound server on complexity. The hard problem of being complex enough to perform the tasks required and not too complex to use.
        The issue I'm talking about is that modern workstations are inherently more complex than those simple SB16 era ISA sound cards. An average user doesn't want to know about multiple devices, multiple output ports (e.g. for a pair a stereo speakers you now have 4 different audio jacks in the mobo), or switching of audio streams between multiple sinks/sources/ports. For example, it might be easier to redirect all sound to device A or B, application specific controls may seem too complex for a simple use case. For instance, now each browser tab has a separate entry in the mixer. PW makes this even worse because you can control each channel separately, you can reroute channel L from stream 10 to port 2 in device A and channel R to port 3 in device B. You can even clone the streams and whatnot. The carla GUI interface is totally useless if you have 200 tabs and 5 audio devices with 20 ports. It's good for pro audio, but I don't get how normal users work with PW. Maybe they'll still use the Pulseaudio pavucontrol?

        Comment

        Working...
        X