The start of Audio pages

Wed May 12 16:24:23 UTC 2010

Hi,

On Wed, May 12, 2010 at 9:46 AM, Brad Figg <brad.figg at canonical.com> wrote:
> https://wiki.ubuntu.com/Audio

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.

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.

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,
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
the countless issues you can have, even if a given API appears to be
supported at face value. Sometimes the audio stack between the
application and the sound card is simply incompatible because of
various obscure things that may or may not be supported by one of the
elements of the chain -- buffering metrics, sample formats, etc.

If I go back 4 or 5 years to a time when I knew very little about
Linux audio, a wiki addressing at least the following things would
have saved me countless hours of trial and error:

*How to figure out what audio APIs are supported by an application,
and what backends those APIs support (if the API supports backends)
*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
*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
*How to use gst-launch-0.10, which has generally well-behaving and
verbose audio sinks, to test various audio APIs (JACK, ALSA, OSS,
PulseAudio)
*Running apps that require JACK (Ardour, IDJC) without removing or
disabling Pulseaudio, by editing default.pa
*Running apps that require OSS (Quake 3, Teamspeak 2) without removing
or disabling Pulseaudio, via osspd
*Running alsa-info.sh and getting help from audio gurus with tweaking
the module parameters (as is often required on partially-supported
hardware)

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.

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.
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.

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. :)

Regards,

Sean

>
> --
> Brad Figg brad.figg at canonical.com http://www.canonical.com
>
> --
> kernel-team mailing list
> kernel-team at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team
>