No announcement yet.

PulseAudio Adds Memfd Transport Support

  • Filter
  • Time
  • Show
Clear All
new posts

  • #51
    Originally posted by Rubble Monkey View Post
    Am I the only one who believes in the KISS principle? The smaller a program the easier it is to fix bugs, that should be obvious.
    How long did it take to make PulseAudio usable I wonder, and will it stay that way?
    Maybe we should just call the opposite of the KISS principle the Lennart Poettering principle.
    Does anyone remember why LibreSSL got started? Cutting the unused crap out of OpenSSL made it more secure and stable!
    As a software engineer I feel a strong urge to headbutt you and people like you, for misstating what KISS and the UNIX principle actually mean in practice.
    Just so you know, the first S in KISS stands for "simple", not "small".

    You can have generally simple programs at 10,000 lines and you can have overly complex ones at 1,000 lines.

    EDIT: Oh yea. And the KISS principle applies to modules of code, not just single use applications. It would be freaking stupid if it didn't and one program suddenly turned into 10.
    Last edited by unixfan2001; 28 April 2016, 08:39 AM.


    • #52
      Originally posted by debianxfce View Post

      Gstreamer is for desktop multiple audio streams. Gstreamer is much better, because it is used with embedded devices. Jackd is for pro audio. Pulseaudio is crap software.
      For the one-hundredth time! Either actually prove your point or stop it! GStreamer is NOT a sound server.

      Says so right in their FAQ too.

      Is GStreamer a sound server ?

      No, GStreamer is not a soundserver. GStreamer does however have plugins supporting most of the major soundservers available today, including pulseaudio, ESD, aRTSd, Jack and others.
      Either you're a freaking genius who somehow managed to build GStreamer into its own independent soundserver or you're full of it and don't know how your own computer works.


      • #53
        Originally posted by SaucyJack View Post
        That individual bug was an issue for months before it got fixed
        i had no that bug, so that bug is your problem, not mine. and not pulseaudio's, because i use pulseaudio as provided by my distro without problems. see, i am sane, you are crazy


        • #54
          Originally posted by SaucyJack View Post
          'Oh he's just an arch user, they're like that so we'll continue to ignore the horrible issues'
          there are manu smart arch users. maintainters of arch pulseaudio and systemd packages are arch users for example. but also there are some noisy idiots among arch users


          • #55
            Originally posted by debianxfce View Post
            Gstreamer is for desktop multiple audio streams. Gstreamer is much better, because it is used with embedded devices
            gstreamer streams audo to pulse. it is not much better, it is higher level component. again quick google sears could have saved you from embarrassment


            • #56
              Originally posted by debianxfce View Post
              ... and never played games.
              so, games are broken on debian + xfce. one more reason to not use it


              • #57
                Originally posted by debianxfce View Post
                Use top, there you see tha pulseaudio takes a lot of cpu time, 1-20%.
                my top shows 60 lines. lower half or so shows 0.0% cpu usage. pulseaudio didn't even make it into those 60 top lines. why did you break your system?


                • #58
                  Originally posted by patrakov View Post
                  Dmix didn't have this "assigned work" problem at all, each process did its resampling and mixing by itself
                  you can't do mixing by each process, they have to cooperate which breaks your nice container picture


                  • #59
                    Originally posted by mdias View Post

                    You must not forget that we're talking about an audio server here. Keeping it simple isn't really that easy. The program must:
                    - manage multi-channel cards
                    - inputs and outputs
                    - multiple cards
                    - multiple sampling frequencies and resampling
                    - all of these playing at the same time without issues
                    - hot plugging of soundcards (think USB headsets that have their own audio processing)
                    - bluetooth audio devices support
                    - be precise about timing/latency
                    - deal with a backend (ALSA) whose quality vary with hardware (some emit proper interrupts when buffers need filling, others don't work properly that way and need polling strategies, etc..)

                    Splitting such an integrated system into single-responsability programs also doesn't look like a very good idea. Implementing a system to allow such low-level communication between these programs would be a mess, not to mention the overhead...

                    Truth is, PA (assuming same version) is the same everywhere while ALSA is not (each driver may behave differently); so if most people don't have any issues with PA and a few do, there's a high probability the problem is an ALSA driver (or poorly configured PA).

                    [edit] I'm obviously refering to the kernel part of ALSA.
                    I must admit, I didn't realize that ALSA couldn't do some of those things.
                    I know this is kinda beating a dead horse at this point, but why has no one tried to rewrite ALSA?
                    A lot of people still love OSS, and doesn't it do a lot of that stuff by itself?


                    • #60
                      I got the fix for PA since about 10 years.

                      It's called emu10k1 & emu10k2. Using only these since forever so I don't have to use a sound server. These card you can find them for 5$ too.