Announcement

Collapse
No announcement yet.

Google Chrome/Chromium Now Supports PulseAudio

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

  • #16
    I am not sure if you realize that PA can not directly be compared to ALSA and OSS.

    PA is only a soundserver/abstraction layer that either outputs to ALSA or OSS (or even both at the same time).
    Your argument is therefore reduced to the feature lacking driver for USB Audio. USB Audio indeed sucks on OSS.

    But there are other (mostly PCI) cards that use OSS to its full potential. With them you have per application volume control, very low latency kernel space mixing (nothing like ~8192 samples as with dmix) and high quality sample rate conversion.

    But then Intel HDA (AFAIK the only card that uses PM) has no Power Management in OSS so Notebooks should stick with ALSA. Other than that the HDA driver of OSS is fine and full featured (and supports even things like manually and seperately muting Headphones or internal speakers)

    So for (IMHO) crappy gaming usb headsets: ALSA with PA
    For Notebooks with Intel HDA: ALSA (PA optionally)
    For (supported) HQ PCI Audio: OSS4 (PA optionally but not really any benefit)

    On the other hand I dont feel like OSS4 development is going anywhere at the moment. Maybe a reinclusion in the kernel could have prevented that, maybe not.

    I for one use ALSA without pulse as only ALSA supports my RME hdsp at the moment whose low latency mixing cappabilities are sufficient for me.

    Oh and another downside of OSS I forgot: It does not correctly support ACPI and hibernation. The modules must be unloaded (the oss script for that is fine) and after reactivation be reloaded. That can be automated by script but is a bit annoying.
    Last edited by Dorsai!; 08-20-2011, 02:50 AM.

    Comment


    • #17
      Originally posted by delan View Post
      I am unsure if you are confusing the crippled version of "OSS" that is included in the main Linux kernel tree, and the real, actively developed version of OSS. In any case, I am aware of the licensing history and how ALSA came about; but this is irrelevant today as OSS is open source.
      I couldn't imagine how it's NOT relevant. If it wasn't for the history then OSS wouldn't be crippled in Linux. The fact that you have to go through a shitload of extra steps and re-compile and/or reconfigure everything in order to use OSS means that it's a huge PITA for anybody wanting to use it.

      It is a usability nightmare.

      So yeah: If you want to completely ignore all the negative aspects of setting up and using your audio then OSS is not terrible. It is still not going be nearly as good as Alsa or PA, but it is not terrible.

      But I am not going to ignore the first step of using OSS is going to be:

      Step 1. Break everything in your system related to audio

      _that_sucks_

      This is the only attempt of yours so far at making a statement about a drawback of OSS. However, your statement is incomplete. While you say that "audio stuff is not simple", this doesn't automatically imply that an audio implementation must also be "not simple". OSS's use of POSIX file-based semantics (as your negatively-loaded statement describes that "OSS is stuck with") has not presented any drawbacks, and works well, in fact. Could you care to elaborate on why POSIX file-based semantics are inherently bad as you describe, in a way other than "Audio is not simple. File-based I/O is simple. Therefore, they are a bad match."?
      I could. But it's stupid to post a wall of text into why reading and writing to a file is not adequate for modern audio applications. I mean, seriously, how many people here actually understand the concepts of POSIX file semantics? I would have to go on and explain everything about reads, writes, buffering, and all that crap. It is silly.

      POSIX file semantics are:
      open( ), close( ), read( ), write( ), ioctl( ), select( ), poll( ), mmap( )

      So. When I plug in my USB headset which one of those function calls is going to be used to notify my application that a new audio device has been inserted?
      How about buffer control? Which one of those calls is going to be used by a application when it needs to change how the buffers work?
      Or how about low latency operation? How is that suppose to work?

      The answer is "none of them" and "can't do it" and "It doesn't work".

      I mean even for simple applications the file system semantics are not adequate. That is why we have fifos and sockets. Why do people think that reading and writing to a device file is going to be perfectly fine for modern audio systems, but not good enough for your Xterm or your web browser to do even very basic rendering on your display?




      Please do not make false assumptions about how I use audio. While I am certainly not a professional user of audio, I am also not the typical green and pink user either. In addition to this, I don't see myself micro-managing my audio; it works flawlessly and is easy for me to control.

      I am not making assumptions. When you say things like '""I don't see myself micro-managing my audio; it works flawlessly and is easy for me to control.""" then it's pretty easy to understand that your requirements for audio is not that high. Because if it was you'd find that OSS and Alsa is not going to allow that for anything beyond bog standard stuff.

      And it's nothing to do with 'professional audio'. Just stupid-simple stuff like 'Configure the microphone correctly' is a huge pain in the ass and differs from driver to driver and device to device.

      I mean seriously. For years and years and years when people bitched and moaned about only being able to play one audio stream at a time the standard answer was:
      "It is because your sound card sucks!!!! LOL. Buy one that does hardware mixing and not one of those piece of onboard!"

      (Except, of course, hardware mixing stomps all over your audio quality. but don't tell the 'sound blaster' fanboys.)

      Comment


      • #18
        Originally posted by drag View Post
        I couldn't imagine how it's NOT relevant. If it wasn't for the history then OSS wouldn't be crippled in Linux. The fact that you have to go through a shitload of extra steps and re-compile and/or reconfigure everything in order to use OSS means that it's a huge PITA for anybody wanting to use it.

        It is a usability nightmare.

        So yeah: If you want to completely ignore all the negative aspects of setting up and using your audio then OSS is not terrible. It is still not going be nearly as good as Alsa or PA, but it is not terrible.

        But I am not going to ignore the first step of using OSS is going to be:

        Step 1. Break everything in your system related to audio

        _that_sucks_
        That's funny. Because in my experience, installing OSS is not hard at all. On Debian, Ubuntu, et al., it's a simple case of removing the PulseAudio and ALSA packages, and installing the oss4-base package, and sound works. Even on Gentoo, which is often lauded as a 'difficult' distro to use, it consists of all of two steps:
        1. emerge oss-devel; /etc/init.d/oss start; rc-update add oss
        2. add 'oss' to the USE flags of any relevant packages and re-emerge them

        Comment


        • #19
          OSS is problematic to install only if your alsa soundsystem is hardwired into the kernel. If it is compiled as a module (as in most distros) you are fine. OSS init script does the rest.

          It even recompiles the modules by itself if you change to a new kernel. Much less hassle than using nvidia drivers or any other third party kernel module.
          Last edited by Dorsai!; 08-20-2011, 02:57 AM.

          Comment


          • #20
            I call BS.

            So all I have to do is:
            apt-get install oss4-base

            And now my SPDIF-out is all of a sudden going to magically work with all my applications?

            It is hilarious how it's easy to paraphrase what you guys are saying as:
            "Yeah if you completely ignore everything that needs to be done then it's easy to do."

            Just uninstall everything and reinstall it, no problem!

            Comment


            • #21
              Originally posted by drag View Post
              I call BS.

              So all I have to do is:
              apt-get install oss4-base

              And now my SPDIF-out is all of a sudden going to magically work with all my applications?

              It is hilarious how it's easy to paraphrase what you guys are saying is:
              "Yeah if you completely ignore everything that needs to be done then it's easy to do."
              It certainly did for me.

              Comment


              • #22
                I'm not arguing with you but...

                Originally posted by drag View Post
                I couldn't imagine how it's NOT relevant. If it wasn't for the history then OSS wouldn't be crippled in Linux. The fact that you have to go through a shitload of extra steps and re-compile and/or reconfigure everything in order to use OSS means that it's a huge PITA for anybody wanting to use it.

                It is a usability nightmare.

                So yeah: If you want to completely ignore all the negative aspects of setting up and using your audio then OSS is not terrible. It is still not going be nearly as good as Alsa or PA, but it is not terrible.

                But I am not going to ignore the first step of using OSS is going to be:

                Step 1. Break everything in your system related to audio

                _that_sucks_



                I could. But it's stupid to post a wall of text into why reading and writing to a file is not adequate for modern audio applications. I mean, seriously, how many people here actually understand the concepts of POSIX file semantics? I would have to go on and explain everything about reads, writes, buffering, and all that crap. It is silly.

                POSIX file semantics are:
                open( ), close( ), read( ), write( ), ioctl( ), select( ), poll( ), mmap( )

                So. When I plug in my USB headset which one of those function calls is going to be used to notify my application that a new audio device has been inserted?
                How about buffer control? Which one of those calls is going to be used by a application when it needs to change how the buffers work?
                Or how about low latency operation? How is that suppose to work?
                int ioctl(int fildes, int request, ... /* arg */):

                from http://linux-documentation.com/en/man/man3p/ioctl.html with the appropriate args seems like it would deal with the headphones quite well.
                Perhaps I am missing something since I know that "correct" audio implementations (including those who seemingly disagree with Nyquist/Shannon) are extremely complicated, but these particular things you mentioned seemed quite doable with posix. Even latency seems like it could be dealt with using poll.

                Regardless, I agree with what you since PA has made things nothing but easier for me.

                Comment


                • #23
                  @delan

                  You didn't do any mixer settings. You did not configure any of your applications. You didn't do anything, at all.

                  Zero, nadda.

                  I didn't realize that OSS4 had mind-reading capabilities.
                  Last edited by drag; 08-20-2011, 03:16 AM.

                  Comment


                  • #24
                    Originally posted by liam View Post

                    Regardless, I agree with what you since PA has made things nothing but easier for me.

                    That's the point. It makes things easy to use.

                    It supports all the hardware that is possible for Linux to support at this time. It supports all the configurations that is needed for desktop audio. You don't have to go out and ditch your hardware that works perfectly well in any other OS. You don't have to memorize the specific alsamixer settings for your stuff to work. You don't need arcane knowledge of drivers and configuration utilities with different documentation or anything like that. No editing of text files.

                    _thats_the_point_.

                    It does what is needed to be done.

                    Comment


                    • #25
                      Originally posted by drag View Post
                      @delan

                      You didn't do any mixer settings. You did not configure any of your applications. You didn't do anything, at all.

                      Zero, nadda.

                      I didn't realize that OSS4 had mind-reading capabilities.
                      The default mixer settings are configured sanely such that multichannel and spdif out are working out of the box. Applications that try to play audio will automatically use OSS, if ALSA and PulseAudio are removed.

                      That's the point. It makes things easy to use.

                      It supports all the hardware that is possible for Linux to support at this time. It supports all the configurations that is needed for desktop audio. You don't have to go out and ditch your hardware that works perfectly well in any other OS. You don't have to memorize the specific alsamixer settings for your stuff to work. You don't need arcane knowledge of drivers and configuration utilities with different documentation or anything like that. No editing of text files.

                      _thats_the_point_.

                      It does what is needed to be done.
                      PulseAudio's OSS module is absolute tripe; it does not work for anything other than playing audio. Not even the mixer controls work.

                      Comment


                      • #26
                        The default mixer settings are configured sanely such that multichannel and spdif out are working out of the box. Applications that try to play audio will automatically use OSS, if ALSA and PulseAudio are removed.
                        And when spdif shares the same audio output device as something else?

                        In many audio devices 'multichannel out' and 'spdif out' are mutually exclusive things. You can't have both at the same time. Especially common when you want to use a microphone.


                        PulseAudio's OSS module is absolute tripe; it does not work for anything other than playing audio. Not even the mixer controls work.
                        That's not a bad thing.

                        Comment


                        • #27
                          Originally posted by drag View Post
                          That's not a bad thing.
                          Do tell me, under what circumstances is that "not a bad thing"? Because you don't like OSS?

                          Comment


                          • #28
                            Originally posted by delan View Post
                            Do tell me, under what circumstances is that "not a bad thing"? Because you don't like OSS?
                            Yeah sure. The sooner LInux software abandons legacy and crufty APIs the easier it is for end users and the less likely you are to run into breakage, security problems, and shitty performance.

                            Plus I don't want OSS applications doing stupid stuff with my mixer settings. The less damage they can cause the better off I am. There are a number of times OSS applications and Alsa-only applications do just brain-dead shit to my system because of the hoops that those APIs make application developers jump through to try to make things 'easy' for end users. Especially when it comes to probing/configuring device outputs and trying to get microphones to work properly.

                            Individual applications have no business doing anything like that on the desktop, for the most part. It really just should be managed by a central application.

                            Comment


                            • #29
                              Originally posted by drag View Post
                              Yeah sure. The sooner LInux software abandons legacy and crufty APIs the easier it is for end users and the less likely you are to run into breakage, security problems, and shitty performance.
                              OSS isn't a "legacy and crufty API". I don't know where you got that from.

                              Originally posted by drag View Post
                              Plus I don't want OSS applications doing stupid stuff with my mixer settings. The less damage they can cause the better off I am. There are a number of times OSS applications and Alsa-only applications do just brain-dead shit to my system because of the hoops that those APIs make application developers jump through to try to make things 'easy' for end users. Especially when it comes to probing/configuring device outputs and trying to get microphones to work properly.

                              Individual applications have no business doing anything like that on the desktop, for the most part.
                              You clearly misunderstood my reply. What I meant was that, the PulseAudio module for using OSS, module-oss, is so bad that it can't do any mixing controls. This is mainly due to Lennart Poettering is an arrogant fanboy that is too lazy to get OSS support working. I mean,

                              W: module.c: module-oss is deprecated: Please use module-alsa-card instead of module-oss!
                              just shows it all really. Any sane person knows that deprecation is all about discontinuing one implementation of a feature in favour of another implementation of the same feature, not discontinuing one implementation of a feature in favour of a completely different feature which doesn't work in the original situation.

                              Comment


                              • #30
                                You clearly misunderstood my reply. What I meant was that, the PulseAudio module for using OSS, module-oss, is so bad that it can't do any mixing controls. This is mainly due to Lennart Poettering is an arrogant fanboy that is too lazy to get OSS support working. I mean,
                                Oh. My apologies then.

                                Yeah. I don't know why I (or anybody else) would care about OSS output support for PA in Linux (PA over OSS) when I can use Alsa drivers for setting up my hardware and have something much better (PA over Alsa).

                                Now OSS output for PA in FreeBSD or something is something else. But I don't see why Lennart Poettering is to blame for shitty FreeBSD support when, obviously, that isn't his focus. It's up for the people that care about BSD support to fix that if it is so broken.

                                OSS-in support is far more important since applications are more important then drivers. It is too bad that some old binaries that require things like mmap support don't work better in modern Linux. (I don't want them to have mixer controls, of course.)
                                Last edited by drag; 08-20-2011, 04:21 AM.

                                Comment

                                Working...
                                X