Announcement

Collapse
No announcement yet.

ALSA 1.0.25 Is Out With Many Linux Audio Changes

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

  • #11
    Originally posted by r1348 View Post
    I still don't see why you don't want to use Pulseaudio. Just because some dudes on IRC told you not to?
    Seriously, I use Pulseaudio since it was first integrated in Fedora, and I never had a problem with it. I know there were rough edges at the beginning (specially on Ubuntu) but most of the bugs have been sorted out.
    Also, I think it's a cleaner design to leave drivers to alsa, and mixing/routing to Pulseaudio. As you said, dmix turned out to be a disappointment, ask yourself why.
    I do use pulseaudio :-)
    But I don't think it should be necessary to use pulseaudio for something as basic as sane volume control. Of course you are right that it's a clean approach to leave the drivers to alsa and the rest to pulseaudio. But then alsa should be stripped down to be just a thing hardware abstraction layer with a well-defined interface for sound servers, and shouldn't be used directly by anything but a sound server. And since that won't happen, I think they should provide an out-of-the-box usable system with alsa alone. Of course "usable" is debatable here.
    On another note, pulseaudio still isn't trouble free, especially not for apps only supporting alsa output. It works well enough at the moment, though.

    So my point basically is that they really should get together (alsa, pulseaudio, jack, etc) and decide which project does what and provide good standardized interfaces, easy setup and consistent behaviour. There have been some articles here on phoronix about game developers calling the linux sound situation insane and unprogrammable in a general way ... and still nothing happens to resolve those issues.


    Originally posted by curaga View Post
    Just in case you're not aware, OSS4 has per-app volume control.
    I know, but OSS v4 is not an option with a vanilla linux kernel afaik.

    Comment


    • #12
      Originally posted by r1348 View Post
      I still don't see why you don't want to use Pulseaudio. Just because some dudes on IRC told you not to?
      Seriously, I use Pulseaudio since it was first integrated in Fedora, and I never had a problem with it. I know there were rough edges at the beginning (specially on Ubuntu) but most of the bugs have been sorted out.
      Also, I think it's a cleaner design to leave drivers to alsa, and mixing/routing to Pulseaudio. As you said, dmix turned out to be a disappointment, ask yourself why.
      I do use pulseaudio :-)
      But I don't think it should be necessary to use pulseaudio for something as basic as sane volume control. Of course you are right that it's a clean approach to leave the drivers to alsa and the rest to pulseaudio. But then alsa should be stripped down to be just a thing hardware abstraction layer with a well-defined interface for sound servers, and shouldn't be used directly by anything but a sound server. And since that won't happen, I think they should provide an out-of-the-box usable system with alsa alone. Of course "usable" is debatable here.
      On another note, pulseaudio still isn't trouble free, especially not for apps only supporting alsa output. It works well enough at the moment, though.

      So my point basically is that they really should get together (alsa, pulseaudio, jack, etc) and decide which project does what and provide good standardized interfaces, easy setup and consistent behaviour. There have been some articles here on phoronix about game developers calling the linux sound situation insane and unprogrammable in a general way ... and still nothing happens to resolve those issues.


      Originally posted by curaga View Post
      Just in case you're not aware, OSS4 has per-app volume control.
      I know, but OSS v4 is not an option with a vanilla linux kernel afaik.

      Comment


      • #13
        Has anyone seen the addition of 256 subdevices for x-fi chips?

        Two Hundred Fifty Six hardware mixing channels. For each output. Fuck yea.

        aplay -l output is now looooong:

        Comment


        • #14
          Adriano, I'm sure you'd have a field day with all those subdevices

          Now can audacity take advantage of all that?

          Comment


          • #15
            This is for games. On Windows. But since this is Linux, all those mixer channels are useless

            Comment


            • #16
              How would hardwaremixing with those subdevices work? I do not seem to be able to "just use" it like a dmixed device.

              Comment


              • #17
                Originally posted by Dorsai! View Post
                How would hardwaremixing with those subdevices work? I do not seem to be able to "just use" it like a dmixed device.
                AFAIK, you disable dmix (which should happen automatically I think.) A good way to ensure sane defaults are chosen is to delete the /etc/asound.conf and ~/.asoundrc files. Your distribution most probably provides an /etc/asound.conf file that forces dmix.

                According to the ALSA docs, dmix is used automatically only on devices that don't have mixing. So if you delete the file, it should use the hardware mixer. If not, it's time to file a bug report to ALSA upstream.

                Edit:
                If you use PulseAudio, not just plain ALSA, then forget it. PA does not support hardware mixing, and never will. This is what the creator of PA said about it:

                "PA does not make use of hardware mixing. And I don't plan to change that. It's obsolete technology."
                Last edited by RealNC; 01-25-2012, 07:45 PM.

                Comment


                • #18
                  Can someone help me with the problem I described in this post?
                  Thanks.

                  Comment


                  • #19
                    I use ALSA without pulseaudio, but with a very extensive asound.conf. I now got it working.

                    The mistake I made was accessing the subdevice via hw:0,4 which is my spdif, but has only one subdevice. If I use hw:0,0 it works perfectly. Thanks for pointing this out or I would have used high latency dmix until the end of all days.

                    Now the only thing missing from the driver is a way to synchronize to an external clock source on S/PDif input.

                    Comment


                    • #20
                      Originally posted by r1348 View Post
                      I still don't see why you don't want to use Pulseaudio. Just because some dudes on IRC told you not to?
                      Seriously, I use Pulseaudio since it was first integrated in Fedora, and I never had a problem with it. I know there were rough edges at the beginning (specially on Ubuntu) but most of the bugs have been sorted out.
                      Also, I think it's a cleaner design to leave drivers to alsa, and mixing/routing to Pulseaudio. As you said, dmix turned out to be a disappointment, ask yourself why.
                      Reasons or me not to run PA.
                      • Because I have multiple users playing sound at the same time (XBMC and MPD) Which is not a supported pulseaudio configuration... My server/HTPC
                      • Because It doesn't yet work nicely with my DE of choice (XFCE mixer applet doesn't support it, I still run PA, but it is annoying).
                      • It's a pain to setup by hand when not using the binary packages for debian and in general an issue to package last i knew for things like arch and gentoo.


                      I do use it on my desktop, as I really like being able to send the audio from my tablet to my desktop via bluetooth, but I'll keep using ALSA on the server/HTPC untill PA get's its head out of its ass and understands that linux is a multi-user system.

                      Comment

                      Working...
                      X