| lateralus01 | does anyone know how to get a sound card working? specifically the headphone jack??? | 05:58 |
|---|---|---|
| lateralus01 | help | 05:59 |
| === SCHRIVE is now known as nicobroii | ||
| openweek9 | hello | 11:01 |
| === ian_brasil is now known as IAO | ||
| === Milyardo_ is now known as Milyardo | ||
| === goshawk_ is now known as goshawk | ||
| === arvind_k is now known as arvind_khadri | ||
| DKcross | hello people | 21:48 |
| DKcross | i have problems :) im testing karmic koala | 21:48 |
| DKcross | exist any channel for karmic ? | 21:48 |
| Andphe | #ubuntu+1 | 21:49 |
| hggdh | DKcross, go to #ubuntu+1 | 21:49 |
| DKcross | thanks | 21:49 |
| blueyed | Hi. can somebody give me a hint already about debugging Pulseaudio. Until recently "pacmd .. list-sinks" only displayed a null device, now it has alsa as sink, but every non-KDE app still fails to play sound (or crashes on startup). | 22:41 |
| komputes | Is the Audio troubleshooting classroom happening soon? | 22:55 |
| andresmujica | in about 5 minutes... | 22:55 |
| * kamusin ole olé! | 22:56 | |
| komputes | sweeet | 22:56 |
| komputes | hi dtchen ! | 22:56 |
| andresmujica | hi dtchen | 22:56 |
| dtchen | hi | 22:56 |
| dtchen | https://wiki.ubuntu.com/Packaging/Training/Logs/2009-08-28 | 22:56 |
| maco | hello | 22:58 |
| dtchen | ok, hi everyone, tonight we'll be covering the topics listed at https://wiki.ubuntu.com/Packaging/Training/Logs/2009-08-28 | 23:00 |
| dtchen | just to reiterate, we're having a short session on triaging sound bugs in Ubuntu, though many of these procedures are handy for other modern Linux distributions | 23:00 |
| dtchen | for those without access to the wiki currently, here's the agendum: | 23:01 |
| dtchen | # Pedigree of Linux audio | 23:01 |
| dtchen | # Modern sound architecture for x86 laptops/netbooks | 23:01 |
| dtchen | # Triaging audio bugs using Launchpad | 23:01 |
| dtchen | # Common problem(symptom)s and their resolutions/workarounds | 23:01 |
| dtchen | # What's in store for Karmic and Karmic+1 | 23:01 |
| dtchen | i'd like to make this session as interactive as possible, so please feel free to ask questions in #ubuntu-classroom-chat | 23:01 |
| dtchen | ok, let's dive in | 23:02 |
| dtchen | Paraphrasing, ALSA began life as a GPL alternative to the languishing | 23:02 |
| dtchen | OSS 3.x. From the onset, it was clearly designed to place only driver | 23:02 |
| dtchen | and necessary core bits in kernelspace; the more complex and extensible | 23:02 |
| dtchen | parts would be in userspace. | 23:02 |
| dtchen | It's important here to note that despite ALSA having become the "blessed" sound subsystem for Linux 2.6, OSS development has continued outside of the Linux tree; other OSes like the BSDs use some parts of its current version, 4.x, and Solaris has its own "fork" of 4.x. | 23:04 |
| dtchen | Early in Ubuntu development, i.e., 4.10 to 5.04, it was decided to pursue ALSA as the sole supported base. It seemed (as has proven to be) rather intelligent from a resource perspective, given upstreams were focusing on it. | 23:05 |
| dtchen | Briefly, i'll describe the modern sound architecture on an Ubuntu release. Perhaps an ASCII diagram helps: | 23:06 |
| dtchen | using the analog of a stack, it looks something akin to, | 23:07 |
| dtchen | - Rhythmbox - | 23:07 |
| dtchen | - GStreamer - | 23:07 |
| dtchen | - PulseAudio - | 23:07 |
| dtchen | - ALSA (-lib, userspace) - | 23:07 |
| dtchen | - ALSA (linux, kernelspace) - | 23:08 |
| dtchen | - hardware - | 23:08 |
| dtchen | i.e., when you're listening to music using Rhythmbox in Ubuntu Jaunty, you're hitting six different parts of what i call the "audio stack" | 23:08 |
| dtchen | triaging sound bugs in Ubuntu (and yes, in Linux generally) is complicated by the fact that every single part of that stack above is rife with problems | 23:09 |
| dtchen | the most difficult parts to debug tend to be lower in the stack, e.g., hardware through PulseAudio | 23:09 |
| dtchen | Because we're currently mid-stride (well, toward the latter end of) development of Karmic, there are a lot of fast-moving parts in the stack. | 23:10 |
| dtchen | For people who use Karmic, you've likely seen my posts to the ubuntu-devel and ubuntu-devel-discuss mailing lists requesting testing using the ubuntu-audio-dev PPA | 23:11 |
| dtchen | (https://launchpad.net/~ubuntu-audio-dev/+archive/ppa) | 23:11 |
| dtchen | Now that Karmic is in Feature Freeze, it is more important than ever to track that PPA closely. | 23:11 |
| dtchen | 18:10 < Out_Cold> so were do OSS plugins fit in for the stack? | 23:12 |
| dtchen | It depends which OSS plugins Out_Cold's referring to. | 23:12 |
| maco | <Out_Cold> alsa-oss | 23:13 |
| dtchen | For instance, ALSA itself offers an older OSS compatibility option via two loadable kernel modules, snd-oss-pcm and snd-oss-mixer | 23:13 |
| dtchen | Sorry, that would be snd-pcm-oss and snd-mixer-oss | 23:14 |
| dtchen | Those two modules are loaded by default in Ubuntu and supported remixes to make accessibility (a11y) programs work more smoothly | 23:14 |
| dtchen | (I'll cover that bit toward the end of this discussion.) | 23:15 |
| maco | looks like no further questions | 23:15 |
| dtchen | Having snd-{pcm,mixer}-oss loaded gives userspace /dev/dsp*, /dev/mixer*, /dev/audio*, and other OSS-provided devices. | 23:15 |
| dtchen | So that's one major class of "OSS compatibility". However, there is another class known as "wrappers"; these would be things like edsp, alsa-oss, padsp, etc. | 23:16 |
| bcurtiswx | ok sorry for the delay | 23:17 |
| bcurtiswx | have we started? | 23:17 |
| dtchen | This latter class of "wrappers" is simply LD_PRELOAD hacks. They're often not terribly effective, though they do suffice for an increasingly shrinking subset of popular programs. | 23:17 |
| dtchen | (On the horizon is something called OSSp; we'll cover that briefly toward the end.) | 23:18 |
| limcore | hello | 23:18 |
| dtchen | Out_Cold's question regarding alsa-oss actually sits at the upper ALSA layer, i.e., in userspace. It attempts to redirect accesses to the OSS devices and route them through ALSA. | 23:20 |
| dtchen | (the same holds for all wrappers, OSSp notwithstanding) | 23:20 |
| dtchen | So, that should cover Out_Cold's question. | 23:20 |
| andresmujica | stefg: any plans to have a (well needed) system wide EQ in the near future? | 23:20 |
| Out_Cold | ty | 23:20 |
| dtchen | There have been efforts to place an ALSA eq, though they have stalled. There is currently a branch of PulseAudio (PA) that has eq functionality. Calls for testers are on the pulseaudio-discuss mailing list. | 23:21 |
| dtchen | (We're not really considering LADPSA at this point to be "eq".) | 23:22 |
| dtchen | Any further questions? | 23:22 |
| maco | <limcore> so, pulse audio fails in multi users scenario. can we do something about this | 23:22 |
| dtchen | That question needs more detail/context. Are we talking multiseat? | 23:23 |
| limcore | PA is per-user not system wide. This is not good for my use case. When I switched it to system-wide, it works very badly | 23:23 |
| dtchen | PulseAudio has plans for multiseat, yes, but they will not land for Fedora 12, Ubuntu Karmic, etc. | 23:24 |
| limcore | in system-wide mode, often (on my hardware at least) sound gets very distorted, skipping/jumping (like some buffer fragments problems or something) | 23:24 |
| limcore | then it will be not possible for another HALF YEAR to do trivial task like "user on VT-7 plays the music, and it keeps playing even when I switch VT's" ? | 23:25 |
| dtchen | limcore: it's possible now, yes. It's not trivial using PA, fairly trivial using ALSA directly, but neither option is ideal. | 23:25 |
| limcore | PA is the ideal solution / the goal for ubuntu right? | 23:26 |
| dtchen | ok, i have a lot more background to cover before we can get to triaging, so let's continue. | 23:26 |
| dtchen | (PA is the upstream momentum, so that's Ubuntu's momentum currently.) | 23:26 |
| dtchen | Bringing the discussion back to triaging sound bugs, what we see a lot of are: | 23:27 |
| dtchen | 0. sound muted bugs | 23:27 |
| dtchen | 1. audio anomaly (crackling, popping) bugs | 23:27 |
| dtchen | 2. general infrastructure bugs | 23:27 |
| dtchen | To understand how these three major classes of bugs have arisen, it's useful to look at current commodity (consumer) laptops and netbooks. | 23:28 |
| dtchen | There are two major audio specifications for laptops and netbooks: AC'97 and High Definition Audio (Azalia). | 23:29 |
| dtchen | AC'97 was implemented by many OEMs, perhaps the most popular being the Creative/Sigmatel combination of Live! and Audigy families | 23:30 |
| dtchen | It's important to note that both AC'97 and HDA are specifications, so looking at "lspci -v" to get e.g., Audio device: nVidia Corporation MCP67 High Definition Audio (rev a1), is pretty useless | 23:31 |
| dtchen | Because AC'97 and HDA are only specs, OEMs have popularized lots of features that require driver enablement, which means that resources must be devoted to implementing them correctly on every OS. | 23:32 |
| Out_Cold | lspci -v | 23:33 |
| stefg | aplay -l | 23:33 |
| dtchen | For modern laptops and netbooks, we're dealing essentially with HDA codecs and controllers, and that brings new classes of headaches. | 23:34 |
| dtchen | One of the reasons for so many regressions between Ubuntu Gutsy and Ubuntu Intrepid was the tightening of codec enforcement. | 23:35 |
| dtchen | This means that features were moved out of the generic driver/parser into codec-specific patch files (you can see these in the Linux source, sound/pci/hda/patch_*.c) | 23:35 |
| dtchen | Further regressions between Intrepid and Jaunty, e.g., internal microphones not working, have been caused by an infrastructure extension | 23:36 |
| dtchen | It used to be that jack-sensing was strictly tied to the driver and could not be manipulated by userspace programs. As of Karmic, that is no longer the case. | 23:37 |
| dtchen | (e.g., when you insert headphones, your laptop's internal speakers mute) | 23:37 |
| === kermiac_ is now known as kermiac | ||
| dtchen | So, now i'll cover the process from cold boot to GNOME session log in for Ubuntu Jaunty. | 23:38 |
| dtchen | When you power on your laptop, your BIOS either programs the HDA codec for you, or it does not. Whether it does depends solely on the OEM making the machine. | 23:39 |
| dtchen | Let's say you have a BIOS that programs the HDA codec for you, and it does so correctly. Life is good; you hear the drum sound for GDM; you login, hear the login sound, and continue on your merry way. | 23:40 |
| dtchen | Let's say you have a BIOS that programs the HDA codec for you incorrectly, e.g., flipping two of the initialisation verbs so your headphone jack does nothing. | 23:41 |
| dtchen | Here's how the ALSA driver works: | 23:41 |
| dtchen | udev will match the modalias for your vendor and device and load the appropriate codec and controller kernel modules | 23:42 |
| dtchen | once the controller module initialises, it runs through the generic parser unless it sees a more specific match (which actually short-circuits the match) | 23:43 |
| dtchen | once the specific match is made, the appropriate patch path for your HDA codec is used | 23:43 |
| dtchen | at this point, things get interesting: if there's a BIOS setup of the verb tables, that existing setup is used UNLESS there's a hard-coded model quirk passed via the command line (e.g., model=foo) or there's a hard-coded model quirk in the driver source itself | 23:45 |
| dtchen | essentially, the order is always: | 23:45 |
| dtchen | 0. use passed quirk | 23:45 |
| dtchen | 1. use driver source quirk | 23:45 |
| dtchen | 2. use existing verb table state | 23:45 |
| dtchen | Note that (2) does not imply that the codec was correctly configured! | 23:46 |
| dtchen | (the driver has no way to know if what exists is correct) | 23:46 |
| dtchen | So, if your BIOS unluckily configures the table incorrectly, you stand a chance to reconfigure it on-the-fly using a tool called hda-verb. | 23:47 |
| maco | dtchen: glossary request: <limcore> what is this "verb" | 23:48 |
| dtchen | you need to load snd-hwdep to use hda-verb | 23:48 |
| dtchen | verb tables are essentially "initial states" | 23:48 |
| dtchen | aka "set this pin to route here" | 23:48 |
| dtchen | the HDA specification has a whole list of verbs/commands | 23:49 |
| limcore | and each sound card + main board pair needs some proper setup "verb"? | 23:50 |
| dtchen | Now, we can move on to the heart of the discussion, which is triaging | 23:50 |
| zyb | verb from german Verbindung =Connection ? | 23:50 |
| bcurtiswx | questions in #ubuntu-classroom-chat please | 23:50 |
| dtchen | let's return to the list above: | 23:50 |
| dtchen | 18:27 < dtchen> 0. sound muted bugs | 23:50 |
| dtchen | 18:27 < dtchen> 1. audio anomaly (crackling, popping) bugs | 23:50 |
| dtchen | 18:27 < dtchen> 2. general infrastructure bugs | 23:50 |
| dtchen | The first thing to remember when you're triaging sound bugs is that you may be dealing with multiple parts of the stack: | 23:51 |
| dtchen | 18:07 < dtchen> - Rhythmbox - | 23:51 |
| dtchen | 18:07 < dtchen> - GStreamer - | 23:51 |
| dtchen | 18:07 < dtchen> - PulseAudio - | 23:51 |
| dtchen | 18:07 < dtchen> - ALSA (-lib, userspace) - | 23:51 |
| dtchen | 18:08 < dtchen> - ALSA (linux, kernelspace) - | 23:51 |
| dtchen | 18:08 < dtchen> - hardware - | 23:51 |
| dtchen | Realising that, the first action is to identify which part(s) of the stack are pertinent | 23:52 |
| dtchen | After identifying which parts of the stack are pertinent, open a task for each portion of the stack | 23:53 |
| dtchen | for simplicity, i'll use the following source packages: | 23:53 |
| dtchen | kernelspace/driver -> linux | 23:53 |
| dtchen | userspace/-lib -> alsa-lib or alsa-plugins | 23:53 |
| dtchen | the rest are self-explanatory, so let's focus on how to differentiate between linux, alsa-lib, and alsa-plugins | 23:54 |
| dtchen | first of all, please don't triage bugs against alsa-driver when you see them opened by apport | 23:54 |
| dtchen | instead, please migrate them to linux | 23:54 |
| dtchen | the alsa-driver source package is to be used only when the bug reporter has either explicitly mentioned using module-assistant with alsa-source or mentioned a bug in the modprobe.d conffiles associated with ALSA (linux-sound-base and/or alsa-base) | 23:55 |
| dtchen | so, a typical work flow might be: | 23:56 |
| dtchen | user A: my sound doesn't work! | 23:56 |
| dtchen | brave triager: please file a bug using "ubuntu-bug alsa-base" | 23:56 |
| dtchen | user A: ok, see bug #7000000 | 23:56 |
| dtchen | brave triager: ok, i'm moving bug #7000000 to affect linux instead of alsa-driver | 23:57 |
| dtchen | ok, with that covered, let's cover the easiest part first: | 23:57 |
| dtchen | alsa-plugins bugs are ones like "Skype didn't work until I downloaded V2.1" | 23:58 |
| dtchen | or "OpenArena explodes when I use PulseAudio" (thanks, fta) | 23:58 |
| dtchen | or "32-bit Adobe Flash on my 64-bit machine makes a spoo noise, and my cat died" | 23:59 |
| dtchen | In other words, alsa-plugins are ones where the PulseAudio reroute is clearly to blame | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!