Top five wrong ways to fix your audio

Posted on 2012-07-13 by David Henningsson

The audio stack in Linux/Ubuntu evolves over time. What used to be good advice is not necessarily good advice anymore. (That also means, that if you happen to read this blog post in 2019 or something, don’t trust it!)
Here are some things that people try, and sometimes they even fix the problem, but are often bad in one way or the other. Or at least, they have side effects one needs to be aware of. So – while there are valid exceptions, as a rule of thumb, don’t do the following:

5. Don’t add your user to the “audio” group

A user has access to the audio card if that person is either logged in – both VT and GUI login counts, but not SSH logins, or if that user is in the “audio” group. However, on the level of access we’re talking about here, only one user has access at a time. So the typical problem scenario goes like:

  • User Homer has an audio issue, and tries to fix it by adding himself to the audio group. This doesn’t help to resolve the problem.
  • Homer discovers his audio is muted, and unmutes it. Happy to have his audio issue resolved, he forgets he’s still in the audio group, or doesn’t realise it leads to problems.
  • User Marge comes and wants to borrow the computer. Homer does a fast-user-switching so Marge can log in.
  • Because Homer is in the audio group, he has still access to the audio device. If some software, e g PulseAudio, has the audio device opened, it blocks access to other software trying to use it.
  • Now Marge has an audio issue!

I’ve written a longer article about the audio group here. In short, there are some usages for it, including that it is also the standard group name for assigning realtime priorities when used together with JACK. But don’t leave a user in the audio group unless you have a good reason.

4. Don’t try different “model” strings

A common way to try to get HDA Intel soundcards to work is to edit /etc/modprobe.d/alsa-base.conf and add the following line:

options snd-hda-intel model=[something]

…where [something] are values you find in some file. Contrary to official documentation, this is in most cases obsolete. In particular, avoid model=generic – that is almost guaranteed to give you trouble. In many cases, when trying different models, you will find that you might fix one thing but break another.
In fact, there is only one model to try, and that is model=auto. If your machine happen to be one of those quirked to use an older model parser, changing to model=auto can improve the situation.

Instead do:
It still happens that BIOS/UEFI assigns the wrong values to pin nodes, which causes an output or input not to work correctly. If so, I recommend trying to tweak this with hda-jack-retask.
In some cases, trying different modules can actually be okay – sometimes, these models point to lightweight fixups instead of the earlier, more heavyweight code that was used in previous kernels. (In this context, I have to mention that Takashi Iwai has done a fantastic job of converting the older models to the newer auto-parser.)

3. Don’t upgrade ALSA drivers by following random blog posts

I’ve seen far too many people reporting bugs on Launchpad where they’ve been following some random blog post that tells you how to upgrade ALSA, and are having audio issues as a result. These guides are of varying quality and often come without good uninstall instructions, so you have no way to revert in case the upgrade did not solve your problem, or broke something else.

First, something not everybody is aware of: 95% of ALSA code is in the kernel, and follows the kernel’s release cycle. That means that even if “/proc/asound/version” says something that was released a year or two ago, don’t panic. It’s the kernel release that tells you how new your sound drivers are, so if you have a new kernel, and you see an ALSA release coming out, you are unlikely to gain from an upgrade.

Instead do:
In some case you do have an old kernel, and newer sound drivers can be worth a try. The Ubuntu Audio Developer’s team provides daily snapshot drivers for HDA Intel cards. Guide is available here and it also comes with proper uninstall instructions.
In the past we have also provided drivers for other cards, but due to the maintenance required to keep this up-to-date, in combination with that the vast majority of people’s bugs concern HDA Intel anyway, this support has been discontinued.

2. Don’t purge PulseAudio

First, PulseAudio itself isn’t perfect, some of the bindings to PulseAudio aren’t perfect, and some of the drivers are not perfect in the way PulseAudio wants to use it either. So there might be valid reasons to temporarily move it out of your way, even if it would be better to actually fix the problem and submit a bug fix patch (if you’re capable of doing so).
But don’t try uninstalling the PulseAudio package, as it has far too many dependencies.

Instead do:
If you just need direct access to your sound card, you can run the “pasuspender” command. You can either run “pasuspender” (in a terminal) to make PulseAudio stay away for the duration of the application. Or if you think that’s simpler, just run “pasuspender bash” (in a terminal), start your application through the menu/dash/whatever you prefer, and when you’re done, write “exit” in the terminal.
If you need to stop the PulseAudio process completely, execute these commands:

echo autospawn=no > ~/.pulse/client.conf
pulseaudio -k

If you need PulseAudio back again, remove ~/.pulse/client.conf, then try to start an application that uses PulseAudio, and it should start automatically.

Unexpected side effects:

  • The Gnome sound settings, the sound indicator and the volume up/down keys relies on PulseAudio, so they won’t work when PulseAudio is off.
  • PulseAudio mixes audio, so that means that only one application at a time can output audio if PulseAudio is disabled (and you aren’t using some other sound server).
  • Several applications have PulseAudio backends. Some of them will need reconfiguration to use ALSA directly, some will just automatically redirect themselves, and some won’t work at all.
  • Bluetooth audio might not work without PulseAudio.

1. Don’t replace ALSA with OSS

OSS was the standard used before ALSA came along. These days, ALSA is much better, both when it comes to hardware support, and when it comes to how much software that supports outputting sound to either sound system. OSS is also entirely unsupported, at least by Ubuntu. In addition, I’m not sure exactly how to get back to a working system after you’ve tried OSS…!

Instead do:
If you know your problem is in ALSA, either drivers or userspace, try to track down and/or fix the bug, and talk to us about it. If you’re running Ubuntu, file a bug against the alsa-driver package. You can also contact the alsa-devel mailinglist. While we won’t guarantee responses due to the high volume of bugs/traffic, we are often able to help out.

Final notes

Note 1. HDA Intel cards are the built-in audio inputs and outputs on your motherboard (at least if you bought your computer after ~2006 or so). HDMI and DisplayPort audio are also HDA Intel cards, but they are covered in more detail here.

Note 2. I have had some problems with spammers posting spam comments to my blog post. I don’t want to spend too much time just reading spam and marking it as such, so I might close for comments in a relatively short period. Sorry for the inconvenience.

This entry was posted in PulseAudio, Uncategorized and tagged PulseAudio, ubuntu. Bookmark the permalink.

17 Responses to Top five wrong ways to fix your audio

  1. spacer Flimm says:
    2012-07-13 at 18:56

    Thank you for this resource. Hopefully, people will come across this when they’re debugging sound problems.

    How did you learn all this? I have often said that I would love to read a comprehensive book on sound on Linux. All the resources I’ve come across are random blog posts I’m not sure I can trust. How can I learn how Pulseaudo, ALSA, OSS, JACK, ESD and the Linux kernel intersect? Besides reading the source code, of course spacer

    • spacer David Henningsson says:
      2012-07-13 at 19:45

      Good question. The audio stack is indeed quite complex. I guess I learn both by reading source code, and discussing with people (on mailing lists, IRC, etc). These things come naturally when contributing – when faced with a problem, figuring out where to fix it, can sometimes mean you have to go into depth to figure out what the different parts of the stack do and how they intersect. If reading and debugging the source is not giving you an obvious answer, I would go to the primary mailinglists (which are alsa-devel and pulseaudio-discuss, as I deal mostly with ALSA and PulseAudio) and ask for advice.

      I think the problem with writing a book on the “sound on Linux” topic would be that as the pieces of the stack evolves, even the book would become outdated rather quickly.

      And how I’ve learned why these are some of the more common mistakes? Well, from triaging a lot of Launchpad bugs over the last two years I’ve been working at Canonical!

  2. spacer David says:
    2012-07-13 at 19:42

    Perhaps fixing the myriad of audio issues users encounter with Ubuntu should be the priority for canonical as a quick scan of the user forums clearly shows there is a need.

    The amount of user problems fixed by uninstalling and reinstalling the stack is staggering. It is no wonder people look high and low for alternatives to the Canonical way.

    • spacer David Henningsson says:
      2012-07-13 at 20:08

      Well, while I can’t answer for Canonical’s priorities in general, I can tell you that Canonical is not infinite of resources, and that Ubuntu would be nothing without its volunteers. I very much welcome anyone who would like to help out with fixing various bugs the audio stack (but beware as it is not a simple task to achieve). If somebody reading this is serious about wanting to help out, do contact me (or any other member of the Ubuntu audio development team) and we’ll try to set up some mentoring for you (or any other type of assistance that would be helpful – within reasonable limits of course).

      The myriad of audio issues is related to the myriad of audio hardware out there – perhaps no other driver area is so diverse as the audio space. At least if we only count x86 hardware. That’s not an excuse, just an explanation of why fixing things for everybody is so difficult.

      Finally, I doubt your statement about uninstalling and reinstalling the stack. But even if that is true – it is very difficult for anyone to analyse and fix a bug where the user just says “I’ve already fixed it myself and there is no trace left on how it happened”, which is essentially the case when somebody reinstalls the stack (in whatever way that is done).

    • spacer David Henningsson says:
      2012-07-13 at 20:13

      I would also like to add that if people stopped doing these five things, I would probably have slightly more time to fix more “real” issues spacer

  3. spacer Robert Chilson says:
    2012-07-13 at 23:43

    I like to play a ;ot of old First person shooter games like “Unreal Tournament”,Halo and such. but the newer audio systems in ubuntu quit working at about 10.04lts and I found that i could use an oss wraper for alsa and everything works again so that may be useful for those issues instead of messing with the stack. sorta like a workaround.

    • spacer David Henningsson says:
      2012-07-16 at 08:09

      Thanks for the comment. There are different ways of emulating OSS when the kernel uses ALSA, and I haven’t used them myself (and I haven’t played Halo either), so I can’t tell which ones work and which ones does not, for different legacy applications. (But even better would be if someone could actually port the applications to use ALSA or PulseAudio instead!)

      padsp would probably be the preferred choice if it works, at least for simpler applications – it makes the stream controllable through PulseAudio, which makes it easy to control its volume etc in the sound settings, just like other applications.

      What emulation tool did you use for these older games?

  4. spacer FourDollars says:
    2012-07-14 at 09:21

    Hi David,

    Thanks for your great advice.
    However I tried ‘model=auto’ on my iMac 8.1 (Early 2008), and it doesn’t solve the audio issue.
    I have to use ‘model=mbp3′ to make audio working on my iMac, and then use hda-jack-retask to make audio working with better quality.
    But I have to use hda-jack-retask with ‘model=mbp3′ at every system boot because ‘options snd-hda-intel model=mbp3 patch=hda-jack-retask.fw,hda-jack-retask.fw,hda-jack-retask.fw,hda-jack-retask.fw’ doesn’t work for me.

    • spacer David Henningsson says:
      2012-07-16 at 07:56

      Hi!

      Well, there are exceptions, and it wouldn’t surprise me if you iMac is one of the cases where a model parser might work better. That said, I’m wondering why you need to specify a model=xxx string at all? Can you verify that this is still necessary under 12.04 (or 12.10)? And if so, file a bug for it (and point me to it), so we can quirk it by default in the driver.

  5. spacer Stoffe says:
    2012-07-14 at 10:50

    About #5: this will obviously continue to happen as bloggers and forum posters will keep on giving that advice (wrongly). A good OS could help out by warning the user when doing this, outputting some information about “this is probably not what you want” and outline briefly why and the consequences, as well as detecting when somebody has an audio problem, that another user is in the audio group and hogging the system, and pop up a dialog explaining the likely cause. Not perfect, but helpful!

    • spacer David Henningsson says:
      2012-07-16 at 08:27

      I’m not sure exactly how such a warning dialog should be implemented, but it sounds like a good idea to me!

      As for detecting sound card being busy, PulseAudio can do that, and then it just ignores the card for the time being. If you write a patch that at least turns that into a warning, with added info about what application and/or user hogged it (if that is possible?), I could try to help getting it in? That would at least be one step in the right direction.

  6. spacer mniess says:
    2012-07-14 at 16:19

    Can you give some examples, why #5 is bad? I tend to have problems with games run through wine. Additionally Unity really slows games down (setting “unredirect fullscreen windows” in ccsm unfortunately crashes Compiz). So what I do is this:

    I add my user to audio, run “xinit — :1″ from a TTY and in the resulting X session I run the game with pasuspender.

    • spacer David Henningsson says:
      2012-07-16 at 08:16

      Hmm, I’m not a ConsoleKit expert, but I think that when you log in through that TTY, ConsoleKit would give you privileges to use your audio card, so you shouldn’t need to add any user to the “audio” group, it should work anyway.

      As for why it is bad, or at least has some side effects you should be aware of, I’ll just quote what I wrote in this article:

      If you decide you want the user to be in the Audio group, you should know that this user can access the sound card even if he is not logged in. And at the lowest level, only one user/application can grab access to the sound card at the same time.

      So assume, for example, that user A is in the audio group is logged in, and is playing music. User B wants the computer temporarily, so they switch users (via fast-user-switching, without user A logging out). Since A can still use the sound card, A’s music will continue to play and user B can’t access the sound card (regardless of whether B is in the audio group or not).

      Or assume that B is sitting in front of the computer, not using the sound card at the moment. A, who is in the audio group, logs in remotely, and can now grab access to the sound card. Should A decide to do so, this means that B suddenly cannot play audio anymore while A is using it. A can also record from the sound cards inputs, so if the machine e g has a built-in microphone, A could in a sense “spy” on B.

  7. spacer Diego says:
    2012-07-14 at 17:23

    Very useful information, thanks!

    David, I think you meant to type
    “avoid model=generic”
    instead of
    “avoid module=generic”

    • spacer David Henningsson says:
      2012-07-16 at 07:48

      Thanks for the proofreading! I’ve updated the post now.

  8. spacer Holgerw says:
    2012-07-15 at 07:33

    Hello,

    sorry, I don’t want to provoke. But the status quo of pulseaudio – it might be very good somertimes later – isn’t good enough yet for a “better sounding world”. And if Ubuntu makes a Gnome Sound – pulseaudio dongle, well, it is a problem of Ubuntu and Ubuntu users.

    Soundcards like M-Audio Audiophile Pro 24/96 have their own mixers, integrated in alsa-tools-gui. With pulseaudio you get no chance to use all possibilities of this card, and you can read a lot of comments of people, who get no sound with Audiophile and pulseaudio.

    Other effects of using this beta-software are little sound interrupts when doing other things like opening an application, moving application windows or scrolling and so on. So for hearing internet streams or other popular background music this might be not a problem but that kind of music hearing has not to do with “better sounding world”.

    And this beta-software is shipped out in Ubuntu as standard? And sound stuff under Gnome is dongled with pulseaudio?

    Sorry, but in my opinion this is a big mistake.

    Kind regards,
    Holger

    • spacer David Henningsson says:
      2012-07-16 at 08:45

      As for the ICE1712 based cards (such as M-Audio AudioPhile 24/96), I believe a lot was solved with this patch which I wrote a year ago and is present in recent releases of Ubuntu. According to bug 178442, remaining problems are 1) that the volume control names exposed by the kernel are non-standard, so PulseAudio can’t control them and 2) audio might be broken after suspend/resume. Both these issues need to be addressed in the kernel rather than PulseAudio.

      Second, I’m the first to agree that PulseAudio isn’t perfect. I wouldn’t go as far as calling it “beta software” though, just because the behaviour is not optimal for all cards. The thing is, we don’t exactly have another, better, option that we could deploy instead. Some people might think dmix, esd, kmix or just using plain alsa (plughw) is better, and it might even be better for certain individuals’ use cases, but as a whole, I think PulseAudio is the best of all non-perfect options we have.

      So therefore I spend some of my time fixing bugs in PulseAudio and other parts of the stack, hopefully contributing to a “better sounding world” spacer