Making ALSA suck less in GNOME

I read Chris’s blog about ALSA, and it does concern me a little. I think ALSA is most definitely the right direction for us to head in, but if users are experiencing a distinctive difference in audio quality, then this needs fixing, and fixing quick. Personally, I have not noticed the difference, but then again, I rarely use OSS, so I could do with comparing them in more detail.

Although Chris’s post was interesting, one of the comments brought up what I consider the main issue:

The biggest problem with ALSA is that configuring it is beyond any mere mortal. If your stuff doesn’t work out-of-the-box with ALSA, you have zero chance of getting it working yourself. Just try to get the optical output on that nforce4 to work and you’ll see.

Exactly. But, this is not just a problem with ALSA, it is a problem with the presentation of audio in our desktop. My question is – how much of this can we fix at the desktop level? Is there a way we can develop some sane defaults for most users, and at least make a GUI interface to sound that is simple? If you take a card such as the Delta 44 or M-Audio 1010, the configuration gets devilishly difficult due to the number of available inputs/outputs, different types of mixing etc. Even users of these high-end cards should not need to care about this kind of stuff.

I think we have a really strong multimedia stack, and GStreamer is making leaps and bounds in features and stability, but we need to nail that all important middle-ground between application-level multimedia playback and the physical sound card, and this seems to be an area that needs fixing in GNOME. This is incredibly important for Jokosher – we have gone out of our way to make audio production in it as usability and ease-of-use focussed as possible, but the whole user experience falls down if sound card configuration requires a degree in rocket science to use.

So, I ask you all – how much of this is fixable in the desktop, and if not, how much needs to be fixable at the ALSA or kernel layer? Also, how can HAL and FDI files help solve this problem?

  • Mark Brown

    There’s some ongoing work in Alsa to do with simplifying the configuration by presenting a clearer interface to users which you might want to look at (not entirely sure if it’s released yet). This is being driven by the needs of embedded system as much as by the needs of desktop users: they require simplified configurations too and often won’t even have sufficient screen space to display the standard GUIs as things currently stand.

  • Johannes Berg

    I recently wrote snd-aoa, a driver for sound on newer Apple machines. While doing so, I very much battled the alsa API. For example, the alsa userspace libraries insist on making a choice (what should be represented as a drop-down select box) into a bunch of boolean values in the name of backward compatibility. So you end up with the kernel telling alsa: The user here has a choice between a,b and c, but alsa libraries mangle that to 3 boolean values, which then get represented as 3 checkboxes that behave like radio buttons.

    That’s just one of the minor complications.

    HAL, so far, doesn’t have any alsa code.

    What I’d really like to see is a rewrite of the alsa libraries. The in-kernel and kernel/userspace APIs are reasonably thought out, but the alsa libraries that all programs must go through always mangle these into unrecognisable form…

  • Rytmis

    As an example, take the stuff I needed to do to get optical output working on my nForce4 board (running Ubuntu Dapper):

    1. Open Gnome mixer
    2. Switch to the OSS device
    3. Unmute digital output channel and turn up its volume
    4. Switch to ALSA device
    5. Select optical jack output type

    Et voilà, my amp flashed the text “PCM48″ on the screen and sound started working.

    The first time I got this to work was an accident. I would have missed it, had it not been for the text on the amp display, because I was already on the verge of giving up.

    Trying to recreate the steps was a lot more fun. I knew it was possible, but had no idea how.

    Having sensible defaults is a great idea. But even with those, if the controls to change those defaults work in a manner that just doesn’t make any sense, your average user is screwed.

  • Peter

    ALSA clearly “sucks” less than OSS, because of support of various settings and multiple channels. However, OSS sound is clearer sometimes and it is really bugging me, as some bloggers and commentators.

    As far as I see that, ALSA needs more commitment in driver tweaking. It is good to hear that there is work for more accesable configuration system.

    And anyway, each such situation should be debuged and reported in bugzilla level to ALSA project. Only then we can judge about quality of ALSA.

  • Martin S.

    This points to a more general but very important problem. The more desktop users, the more the need for easy configuration and good quality for not just the basic, but even the advanced features rise.

    There needs to be some time invested into designing additional functionality on the desktop level to allow better advanced multimedia configuration for the user.

    As the most basic example where it all already starts to get rocket science for User Joe is the inability to select a different sound card. I am talking on desktop level here, not for individual apps which just use ALSA instead of GStreamer for instance (and always reimplement a bunch of ALSA stuff).

    It should shine like a bit red alert sign, that this is yet not possible and currently overlooked hence switching between a soundcard and a headset should not be something you need to learn GStreamer pipeline stuff for.

    Thinking further, things like multiple channels, midi ports, digital/analog in/outs, integrated effects … oh dear.

    Now the “future” technologies with GStreamer and HAL should allow us to construct a pretty solution. However as noted, this needs some conceptual work being done. GStreamer could probably need some API additions or some subproject that allows clean access for applications to soundcard configuration. The required data for configuration parameters should be provided by HAL which needs extension on that level aswell to grab more data from ALSA/OSS.

    If anyone is interested you might read some stuff on the gstreamer-devel list and post some feedback:

    Asides, talking about the sound quality is from my pov. more a matter of a bug report.

  • bronson

    The single biggest mistake in ALSA is that sound cards come up muted. WTF?? How can the user tell the difference between a broken sound card and a quiet one? Thousands of people have probably given up on alsa when the output was just muted by some random aumix slider waaay over to the right.

    Alsa’s second biggest mistake is not having profiles! Each sound card should have 3 or 4 simple profiles. Load the S/PDIF OUT profile and your IEC958 buttons and sliders all get set properly. That way, if someone loads the S/PDIF OUT profile and doesn’t get S/PDIF output, it’s a bug and the profile can be fixed. Right now it seems like every ALSA support request degenerates into questions about obscure settings before most people say, “I dunno. It works for me!”

    ALSA is horribly overcomplex and very user unfriendly. It currently works for me, but I’m not happy with the amount of time it wasted.

  • Mark Brown

    bronson: As I understand it profiles are exactly the sort of thing that the new configuration stuff was focusing on (including stuff like detecting which inputs & outputs are cabled up, what’s connected to them and switching to an appropriate profile). With sensible default profiles this ought to help with most of the problems you mention.

  • chunkance

    Making ALSA suck less in GNOME…


  • Richard

    Problem is: Alsa exposes ALL features of the installed Audio Chip, which is a good thing, BUT not all soundcards provide the plugs for all the features of a chip, and their configuration needs to be tweaked in subtile ways to fit the installed Hardware.

    Therefore it would propable be needed to provide Profiles for all Soundcards, which is much more work than to provide support for all the available audio-chips. Remember, the alsa team has not that big actually.

  • iltedesko

    Making ALSA suck less in GNOME…


  • OSS Forever! Playing Multiple Sounds Simultaneously

    […] One caveat is that dmix upsamples everything to 48 kHz. If you care about this, you can find the workaround on this page (see “Does dmix affect sound quality?”). Coincidentally, I ranted about Alsa’s difficult nature earlier today. It’s a shame that Linux still doesn’t have a high quality sound architecture. A few months ago we heard that Monty is working to fix a lot of Alsa’s warts. I haven’t heard of any progress since then but, personally, I can’t wait! […]

  • jono

    Hi all,

    Sorry not had time to reply, been really busy.

    When looking at this problem, I think it is important to first identify if these problems are the responsibility of ALSA, and when whether they are fixable. As an example, the ALSA developers may say that easy config is impossible as HAL needs updates, or kernel developers are not implementing certain functionality.

    From the outset though, it seems that these problems can be divided into two areas:

    • Functionality
    • Configuration

    In terms of functionality, I don’t know an awful lot about the subject. I am sure there are reasons why certain things don’t work on cards.

    In terms of configuration, these seems to be the crux. I am convinced that ALSA is a suitable audio framework and can be made easier to use, but there has not been that much effort gone into it. The analogy here are LADSPA effects – out of the box there are no LADSPA effect presets, but as an application developer, it is my responsibility to ensure the application can make use of presets to ease the process. Otherwise, our users would be lost in a world of horizontal sliders and strange settings.

    This really does seem like something that could be solved at the desktop level, and with the quality of our audio stack, I am surprised it has not been solved. Maybe some ALSA developers could comment on these issues, and maybe a GNOME developer can comment on the desktop integration of sound support.

  • Rémi

    I haven’t used alsa-lib directly, but I think that one of the issues with this lib is that it’s easy to mess up.

    At one point, I had some sound and video files that I would play in mplayer, totem, audacious (xmms fork) and bmpx (back when it used xine). All of them used alsa directly (totem through gstreamer) but they all had some minor glitches in how they played the sound.

    Maybe Gnome/Gst peeps should be proactive with the alsa folks and propose evolutions of that lib, get things right (just like gst-0.8 was ok, but gst-0.10 just rocks)

  • Isabella


                       There's no place like ~

  • ForbannelÅ¿e

    ALSA is terrible. I have a feeling it was written by an engineer, for an engineer. Troubleshooting anything that goes awry with sound is a good waste of a day thanks to ALSA. Recently setup icecast to stream but got horrible static screeching with nothing playing. Turns out having the AUX (for Auxiliary I guess?) mixer setting turned up for my tvcard caused it. Ok, so I turn it down and have to bump it again to hear the tv? So I try changing the capture source… which you have to change to the capture setting? Makes no sense to capture capture! growls I’ve been using Linux for 8 years now, even know how to recompile the kernel, and nothing has given me as much grief as ALSA.