The start of Audio pages

[Daniel Chen]

On Wed, May 12, 2010 at 6:24 PM, Sean McNamara <smcnam at gmail.com> wrote:
> There are a _lot_ of issues that are not covered by these pages so
> far. I don't know what the "blessed" Canonical way of doing things is,
> so I'm not sure whether I could contribute information that would be
> accepted after review. But as a bit of an audio connoisseur, I've
> found that less than 50% of native Linux apps work out of the box on
> 10.04. That leaves a *lot* of room for troubleshooting audio that is
> not covered by this :) Personally, I have been able to effect an
> enormous number of workarounds to get almost any audio app working,
> but it often takes some doing. The out of the box experience with
> audio is not very good unless you stick to GNOME and KDE apps. Even
> some apps in the official repositories don't work out of the box.

There are many reasons for this, of which the two most significant are
a lack of consistency between blessed sound backends for
Ubuntu/derivatives and missing driver workarounds for unsupported
hardware. For hysterical raisins, Ubuntu/Edubuntu/Ubuntu Studio Lucid
ships and prefers PulseAudio while offering OSS compatibility through
ALSA; Kubuntu/Xubuntu/Mythbuntu Lucid does not ship (and actively
clashes with) PulseAudio while also offering OSS compatibility through
ALSA. This discrepancy results in a variety of brokenness that needs
to be hacked around in alsa-plugins, libsdl1.2, openal-soft, and so
on. All of these have been patched (to varying degrees of success),
but many of them still are broken because of incorrect pulse
integration. Complicating the picture is the less-than-stellar state
of hardware drivers and the actual hardware itself. Until very
recently, i.e., yesterday, the drivers were incorrectly depending on
the hardware to be precise and accurate. That error has been fixed
upstream and will land in Maverick's release kernel (though not the
current one). Further, Ubuntu has traditionally supported OSS
emulation via ALSA. That support is going away completely in Maverick;
instead, OSSp will be used to route everything attempting OSS access
through pulse. Kubuntu Maverick will also ship with pulse integration
in the newest (development) Qt plus whatever KMix and Phonon bits need
to be patched.

Which leaves us with a lot of broken apps still, as you mention. Well,
some of them aren't broken per se, but they don't integrate well with
JACK or pulse. This isn't such a terrible issue, but the two still
need to be taught to hand off courteously via dbus, so until that bit
is in place, we'll continue to see quite a bit of weeping and gnashing
of teeth. Thus, eliminating integration issues, there remain a *lot*
of apps that require -- for whatever odd reason -- plughw: or even raw
hw: access (ALSA), or they simply don't work with ALSA and require
OSS. For those apps, we need to either fix them (i.e., start by filing
bugs using LP) to not require plughw: or hw:, or we need to test them
heavily with OSSp.

As I mentioned in my plenary at UDS Barcelona, the road to smoothly
working audio apps in Ubuntu and its derivatives is a death march.

> I'd like to ask, what exactly is the intended scope of this branch of
> the wiki? Is it just in the kernel context of getting the kernel level
> of ALSA working? Is it just in the context of getting Rhythmbox to
> play music? Is it just in the context of getting officially supported
> Ubuntu apps (in the `main' repo) working? Is it just in the context of
> getting apps in the Ubuntu repos (main/restricted/universe/multiverse)
> working? Or is it intended to be a general guide to getting
> sound-using apps on Linux to work? The scope, apparently undefined,
> should be explicitly given, or else the content will spew out of
> control, because audio on Linux is such a mess.

The context eventually will cover all, but it must grow there, not
begin there. There are staged bits going in beginning with the driver.
Over time, more layers of the audio stack will be documented with
their associated gotchas.

Be careful to remember the context of the documentation and not just
the possible scope creep. We aren't looking for workarounds to get
sound to work; we're looking for common cases that are easily traced
to known and fixed bugs.

> One of the biggest problems with the current sound stack on Ubuntu is
> that certain APIs are entirely unsupported, or only supported without
> software mixing (which is basically the same as unsupported). That
> list of APIs includes: FMod, OSS/Legacy, JACK. Just one release ago,

Some of these need to be fixed. One isn't being supported directly at
all but will be indirectly through OSSp.

> OpenAL was on that list, since I was unable to get multiple OpenAL
> apps working without upgrading the version of openal-soft. 10.04
> appears to have fixed that. This short list, however, does not address

OpenAL shipping in Lucid is still broken, apparently. It doesn't help
that the release notes for the latest stable version do not mention
the necessity/gravity of the bugfixes in the releases, or that the
Lucid version is a direct sync from Debian testing (which is the
precise version also in unstable), or that the new release was done
far too late for Lucid's release. Sadly we'll have to resort to
mind-numbing things like SRUing an entire library version just to fix
playback issues with MPlayer and WINE.

> *How to figure out what audio APIs are supported by an application,
> and what backends those APIs support (if the API supports backends)

The libraries directly linked by the application often assist greatly
in such an endeavor, but more to the point, we need to stop supporting
APIs that are known to not play well with pulse.

> *How to "peel back the onion" to determine whether each successive
> level of the audio stack works, to isolate which particular level of
> the audio stack fails

I gave a 2.5-hr brain dump yesterday doing just this. Canonical has
hired some competent engineers, too. I'm giving talks at user
conferences. There are many ways to spread this information.

> *How to tell whether an application is using the ALSA device `default'
> (which is alsa<->pulse by default), or is being naughty and trying to
> open hw:0 or something else

alsa-lib actually reveals this information.

> *Running apps that require JACK (Ardour, IDJC) without removing or
> disabling Pulseaudio, by editing default.pa

...which isn't supported (by upstream) as the default mode but
certainly is useful for a significant set of users. However, even that
is just a kludge to some extent. Both JACK and PulseAudio should get
hw: access.

> *Running apps that require OSS (Quake 3, Teamspeak 2) without removing
> or disabling Pulseaudio, via osspd

We'll be doing this in Maverick.

> *Running alsa-info.sh and getting help from audio gurus with tweaking
> the module parameters (as is often required on partially-supported
> hardware)

This only goes part of the way. We'll be using hda-analyzer, hda-emu,
and hda-verb much more proactively.

> There's also an art to hacking /etc/asound.conf in a way that will let
> diverse audio apps work in harmony. Some ALSA apps work with a `plug'
> element before the `pulse' element; some do not. Some only work with
> the `jack' element; some only work with the `pulse' element. In short,
> probably the single most unreliable type of audio app is the ones
> which claim to support "ALSA" -- the number of configurations
> supported by the application's usage of ALSA is often limited to
> approximately 1 -- which means you have to figure out what ALSA PCM
> element(s) were in use as the developer made the software. Hopefully
> it wasn't raw hw:0 or plughw:0, because if they're using mmap(), you
> can throw software mixing out the window, or move on to another API
> that the app (hopefully) supports. Sure, we can live in a fantasy land
> where every app uses the Safe ALSA Subset as defined by Lennart, but
> in the real world that's only occasionally the case.

Well, one can't (shouldn't?) stop people from reinventing the wheel,
but telling them why NIH is partially wasteful is useful, too. It's
true that alsa-lib configuration files allow for limitless ways to
punch yourself in the face, but that isn't a bug, nor is allowing the
app developer freedom to use things like mmap. It's just that to have
pulse as a first-class citizen, certain constraints are necessary.
There won't really be a straightforward way to determine which
ordering of plugs is necessary, because there are enormous
(monotonically increasing) numbers of hardware with interesting
constraints.

Concerning JACK and pulse, documenting alsa-lib configuration files is
good but doesn't resolve the issue at hand: we need better jack2 <->
pulse handoff.

> I am certain that every day, Ubuntu loses one or more users because
> they try some sound-using application, the sound doesn't work, and
> they can't puzzle it out. They really, really, really like their shiny
> new app, but it doesn't play sound, so they go back to Windows because
> Ubuntu is broken in their mind. The wiki may not be something that
> your average joe ends up actually using, but documenting these tricks
> of the trade in one place, in an Ubuntu context, might at least help
> power users get more audio apps working. And if nothing else, it will
> increase awareness of the fact that the audio stack is so fragile.

The time spent losing users is not proportionate to the amount of time
spent fixing bugs. This wiki is not useful for fixing bugs, only
documenting places where bugs have been fixed. While some of the
examples are simple "do this to unmute", eventually the reviewed
information will end up in a format accessible to users. I'd even
argue that the largest class of users don't want to muck with alsa-lib
configuration files. We need to fix the apps upstream.

> Hopefully some of these tricks can become part of the default setup in
> the long term. The general take-away of this message is that there are
> a lot of *viable solutions* to get audio apps in-the-wild to work, but
> since they are not implemented by default, they need to be either
> documented, or integrated into a future Ubuntu release. If this wiki
> page is not the place to document them, please suggest where might be
> the correct place.

Again, documentation is awesome. But documentation of workarounds
quickly explodes into a quagmire of search engine-indexed hell unless
it's maintained, which means clearly removing portions as each
successive Linux distribution release is staged. This requires a lot
of manpower, not just one or two people that "know the stack."

> So, having said all this, feel free to splice any parts of this into
> the Wiki itself. As for the actual method of doing some of the things
> in the bullet points -- I have a pretty good idea of how to write it
> while respecting the Ubuntu package system and so forth, but I'm not
> going to write any of it unless I get the go-ahead from someone. I
> don't want to write it, and then learn that it's out of scope. :)

Everything you've mentioned is in-scope, but clearly we're better off
having documentation *and* bug fixing happening in parallel. It's a
no-brainer as to which is more effective, however.

In short, just write. We'll all peer review. Keep in mind that things
are in flux in Maverick, and portions of the wiki will be useful but
unnecessary in Maverick. Which makes gardening all that much more
critical.

Best,
-Dan