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

  • #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


            • #21
              Hail ALSA, fuck PA

              Originally posted by mazumoto View Post
              I guess there are still no independent volume controls for each application.
              How this doesn't seem to bother most people is completely beyond me. The ability to tune down a game slightly while playing some music with an audio player and still being able to clearly hear people talking on teamspeak or skype and not missing pidgin sound notifications is essential for me.

              But no, not the way alsa works, I have to use pulseaudio for that. Insanity if you ask me.
              useless crap, if you ask me.
              every app already has its volume controls, use it.

              but nooo, we need one more layer of software mixing and useless buffering, riiight...

              Originally posted by RealNC View Post
              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."
              holy shit ! i knew Lennart is somewhere-out-there but this... now i'm genuinely scared.
              all this trend to throw everything onto one chip which now have to satisfy queue of bazillion things in a timely manner sickens me. if this is the future then future sucks !

              Comment


              • #22
                Originally posted by dfx. View Post
                every app already has its volume controls, use it.
                It's too slow; you have to search for it. Im Mumble, I have to bring up the application window, enter the configuration dialog, then find the sound output tab, then the volume slider, change it, then hit the "Apply" button, then change the volume again since most probably I'm not satisfied with the volume, hit "Apply" again to test if it's OK now...

                Per-app volume could be done in ALSA without introducing anything new. It already has dmix. There's no reason to introduce another layer of buffering or anything. Forcing users to use PulseAudio just for per-app volume support is retarded :-/

                Comment


                • #23
                  Originally posted by dfx. View Post
                  useless crap, if you ask me.
                  every app already has its volume controls, use it.

                  but nooo, we need one more layer of software mixing and useless buffering, riiight...
                  I am not sure in general, but KDE applications have the nice feature feature that the pulseaudio volume control and the application volume control are the same thing (when pulseaudio is on), so when you change the application volume you are actually changing the pulseaudio volume. That means you don't need to worry about handling two independent volume controls.

                  Comment


                  • #24
                    Originally posted by RealNC View Post
                    It's too slow; you have to search for it. Im Mumble, I have to bring up the application window, enter the configuration dialog, then find the sound output tab, then the volume slider, change it, then hit the "Apply" button, then change the volume again since most probably I'm not satisfied with the volume, hit "Apply" again to test if it's OK now...
                    What you are describing is bad interface design for the application you are using. With Amarok I just place the mouse cursor over it's icon in systray and use the scroll wheel to adjust the volume in real-time. Also for most KDE apps you can set global key shortcuts to adjust the volume if you prefer to use the keyboard. Pulseaudio could not make it easier that this.

                    Comment


                    • #25
                      Originally posted by mazumoto View Post
                      I know, but OSS v4 is not an option with a vanilla linux kernel afaik.
                      Sure it is, just as any other external module (see Nvidia/AMD drivers, broadcom wifi...). They are GPL licensed and you can build them yourself if your distro doesn't supply packages.

                      Comment


                      • #26
                        Originally posted by Ansla View Post
                        What you are describing is bad interface design for the application you are using. With Amarok I just place the mouse cursor over it's icon in systray and use the scroll wheel to adjust the volume in real-time. Also for most KDE apps you can set global key shortcuts to adjust the volume if you prefer to use the keyboard. Pulseaudio could not make it easier that this.
                        It can. There are other examples. Firefox. Or Konqueror. There's no global volume for those. Or games. No game I know of has a volume control outside of its configuration screen.

                        Per-app volume control is very useful and I don't see why you're against it. It very useful for cases where you need to quickly adjust volumes instead of having to search all over the place for each application.

                        Comment


                        • #27
                          I'm not against it, just don't consider it as an essential feature. If someone will implement it for ALSA I'll ignore it just like I do with the Pulseaudio one. Applications that have sound output as an essential feature (like media players or conference software) usually have volume controls more convenient then opening kmix and searching for the corresponding slider. Games also are usually full-screen so it's more convenient to access their own menu then switching to the desktop, opening kmix, adjusting the volume, then switching back to the game.
                          For browsers as well, I don't see how opening kmix could possibly be easier then adjusting the slider that is right in front of you, in the flash or html5 player.
                          The only use I see for per-application volume control is when you have no idea what application is making the sound and you want to make it stop/lower. But that rarely happened to me...

                          Comment


                          • #28
                            Originally posted by dfx. View Post
                            useless crap, if you ask me.
                            every app already has its volume controls, use it.

                            but nooo, we need one more layer of software mixing and useless buffering, riiight...
                            Yes, but using ONE of those volume controls changes the volume of ALL the other apps as well, because there is just one master volume control. That is the point I'm ranting about.
                            And I'd love not to have to use another layer (PA), but alsa forces me to. That's what I'm ranting about.


                            Originally posted by RealNC View Post
                            Forcing users to use PulseAudio just for per-app volume support is retarded :-/
                            Exactly my point. Especially since I'm probably losing multi-user support for that, as I read in some other posts (didn't have the time yet to search for a solution, but that problem already bit me with PA).

                            Comment


                            • #29
                              Originally posted by mazumoto View Post
                              Yes, but using ONE of those volume controls changes the volume of ALL the other apps as well, because there is just one master volume control. That is the point I'm ranting about.
                              There are few applications that don't actually allow changing just their own volume, all KDE applications allow this (because they use Phonon), while most games use either OpenAL or SDL. The only thing alsa could do (and what Pulseaudio does now) is to provide a unified extra layer that does this adjustment and provide a centralized way to adjust the volume for all running applications.

                              Originally posted by mazumoto View Post
                              And I'd love not to have to use another layer (PA), but alsa forces me to. That's what I'm ranting about.
                              The extra layer must exist, if it were included in ALSA it would just move from user-space to kernel-space, and I don't think that's a good idea, as long as something can be done efficiently in user-space it should not be done in kernel. Besides, the main feature of Pulseaudio and the only reason I use it on my laptop (I don't use Pulseaudio on any of my desktops) is that it allows changing the default output device without restarting the application, and there is no way ALSA can implement this unless it creates it's own user-space daemon. BTW, if Pulseaudio was renamed to alsad and included in alsa-utils would that make you happy?

                              Originally posted by mazumoto View Post
                              Exactly my point. Especially since I'm probably losing multi-user support for that, as I read in some other posts (didn't have the time yet to search for a solution, but that problem already bit me with PA).
                              Multiple users using the soundcard at the same time sounds like a bad idea, but still it should be possible with PA with some extra configuration.

                              Comment


                              • #30
                                Originally posted by Milos_SD View Post
                                I have a problem compiling alsa-utils 1.0.25.
                                I have the same issue. Let me know if you figure it out.

                                Comment

                                Working...
                                X