Announcement

Collapse
No announcement yet.

PulseAudio Adds Memfd Transport Support

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

  • #61
    Originally posted by Rubble Monkey View Post

    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?
    Okay, your parent's post was partially true. I won't say they lied, because ALSA used to not able to do alot of those things.

    Alsa can manage multiple channel cards via alsamixer, but it can be pretty clunky.

    The managing multiple inputs and outputs is one thing that Pulse does very right. ALSA, to my knowledge, is setup to have ONE input and ONE output and -those will not change on the fly.- Meanwhile Pulse's approach is "Everything comes into Pulse, then I check to see where it should go." You can even change an application's output during playback.


    Multiple cards.. see above. Switching playback and input on the fly is something Pulse gets right.

    I can't speak about handling resampling, because I'm not sure what Parent's comment was referring to. Both Alsa and pulse can do resampling though, Alsa doesn't do it "natively" though, it requires plugins.

    Alsa does have dmix, which supports hardware level mixing. Pulse does not support hardware level mixing because a lot of cards don't even have hardware level mixing anymore. Note: I said a lot, SOME do, but a lot don't.

    Pulse, in my experience, is very good about hotplugging. Alsa I had to setup per-device udev rules for. I'll take pulse.

    No problems with Pulse and bluetooth. Debian says: https://wiki.debian.org/Bluetooth/Alsa that bluetooth is annoying with pure alsa.

    Timing and latency... This is where I do have a problem with Pulse. Pulse has gotten better over the years, but they still have a latency problem from time to time. Its not constant, and it is perfectly fine 90% of the time. But every once and awhile, you'll notice a delay.

    ALSA's drivers do have some pretty varied quality. This has gotten better since they began to unify a lot of them, but when Pulse came out.. oh the bugs.


    OSS is all over the place. See: https://wiki.archlinux.org/index.php...sons_with_ALSA

    I looked up Bluetooth specifically; FreeBSD probably has the most 'complete' OSS4 implementation, and the thread that I found (from 2013) said "There is no support for Bluetooth audio at this time." OSS does do mixing and resampling, AFAIK, but it does it in kernel, with decimals, and doing decimal math in kernel is gigantic "no no" in Linux.
    All opinions are my own not those of my employer if you know who they are.

    Comment


    • #62
      I also used to ride the anti-PA bandwagon until I decided to try it out a few years back. I never went back. I do remember experiencing a few minor hiccups but never anything that would seriously break the sound. I fully agree that plain ALSA can still do a fine job as long as you use a static audio configuration and don't need more than to hear some sound from your speakers. If you use BT headsets or have to switch audio streams around dynamically from one audio sink to another, ALSA just doesn't cut it.

      I also wonder why some people tend to think that if what is currently handled by PA was done by ALSA it'd be somehow magically better. Conversely, I wonder if PA would still be getting so much flak if the project hadn't been started by Lennart.

      Comment


      • #63
        Pulseaudio is still giving me trouble. Mainly with steam games. But i do believe the steamruntime uses outdated libs. Basically my audio start crackling annoyingly in some games. Also there is this timing issue in the kernel which causes issues with pulseaudios timing. http://unix.stackexchange.com/questi...-for-hda-intel. Personally i dislike Putins software. Claiming that systemd/udev wouldnt work without taking it under its umbrella however gentoo just took systemds udev code without running systemd for a while until udev got forked. That is just ridiculous and they are duplicating work. I still use systemd though because i like how its unit files work.

        Comment


        • #64
          Originally posted by Rubble Monkey View Post

          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?
          Please note that I never said that ALSA can't do any of those things; I just said that pulse does it. And it must do it to be fully integrated.
          Depending on an ALSA driver to implement high level features would result in PA working differently depending on your sound card; it would basically turn PA into ALSA userspace.

          Perhaps you have hardware that works wonders with a pure ALSA system, but please keep in mind that some of us used to go through hell just to have a 5.1 speaker system working (and being properly detected) one more than one process at a time. Nowadays we just install our favourite distro and we just take for granted that sound will work fine.

          I'm not denying there might be issues here and there, but don't just assume "it's the pulse way"; report your issues, just like you should with ALSA.

          Originally posted by Ericg View Post
          ...
          I can't speak about handling resampling, because I'm not sure what Parent's comment was referring to. Both Alsa and pulse can do resampling though, Alsa doesn't do it "natively" though, it requires plugins.
          ALSA does it with dmix, true, however PA uses the kernel part of ALSA, which doesn't do software resampling AFAIK. Even if PA could somehow use dmix it would be a very weird and perhaps problematic setup to have most high-level features living in PA and this specific one living within ALSA.

          Comment


          • #65
            Originally posted by MadCatX View Post
            I also used to ride the anti-PA bandwagon until I decided to try it out a few years back. I never went back.
            Somehow, these anti-PA dudes proven to be nuts. Sorry, but e.g. ALSA and its api got quite some long-standing issues, and utterly losing sound if some of uncooperative programs exclusively grabbed ALSA is annoying. Not to mention ALSA is picky on sample formats (makes app programming PITA) and PA could afford some neat tricks like being able to recognize e.g. the fact headphones != loudspeakers, storing different volume for each of these for e.g. laptops and somesuch. It also got fancy GUI applet for XFCE. Overall, PA proven to be very pragmatic thing and I'm yet to see any major problems. OTOH I've faced plenty of technical issues in systems without PA.

            Comment


            • #66
              Originally posted by Rubble Monkey View Post
              I know this is kinda beating a dead horse at this point, but why has no one tried to rewrite ALSA?
              alsa is a huge number of kernel drivers. you can't just rewrite all of them, if you had that much manpower, you could just fix remaining buggy ones

              Comment


              • #67
                Originally posted by Ericg View Post
                Alsa does have dmix, which supports hardware level mixing
                dmix is software mixing. hardware mixing is transparent

                Comment


                • #68
                  Originally posted by cj.wijtmans View Post
                  Basically my audio start crackling annoyingly in some games
                  did you report it? if it is some games, developers will not encounter it without pointers

                  Comment

                  Working...
                  X