The start of Audio pages

Brad Figg brad.figg at canonical.com
Fri May 14 06:03:32 UTC 2010


On 05/12/2010 06:24 PM, Sean McNamara wrote:
> 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
>>
>
Sean,

By all means, we welcome any contribution your willing to make. The
general idea of the individual wiki pages under /Audio are to help
diagnose and work through single, specific issues. My thinking is that
it's more difficult for users to wade through pages that are covering a
wide variety of issues while looking for a solution to their problem.
As more content is added we will undoubtedly rework some of the
organization of the pages to make things easier to find.

I'm also interested in people contributing scripts that make it easier
for users to fix their problems as opposed to wading through a long
list of steps to have to manually go through.

Brad
-- 
Brad Figg brad.figg at canonical.com http://www.canonical.com




More information about the kernel-team mailing list