2009-08-28

Agendum

  • Pedigree of Linux audio
  • Modern sound architecture for x86 laptops/netbooks
  • Triaging audio bugs using Launchpad
  • Common problem(symptom)s and their resolutions/workarounds
  • What's in store for Karmic and Karmic+1


   1 17:56 -!- Irssi: #ubuntu-classroom: Total of 97 nicks [1 ops, 0 halfops, 0 voices, 96 normal]
   2 17:56 < komputes> hi dtchen !
   3 17:56 < andresmujica> hi dtchen
   4 17:56 < dtchen> hi
   5 17:56 < dtchen> https://wiki.ubuntu.com/Packaging/Training/Logs/2009-08-28
   6 17:56 -!- Channel #ubuntu-classroom created Sun Nov 26 01:42:45 2006
   7 17:57 -!- SiDi [i=54669719@gateway/web/freenode/x-kmgkecdzlbupmnan] has joined #ubuntu-classroom
   8 17:58 -!- Irssi: Join to #ubuntu-classroom was synced in 110 secs
   9 17:58 < maco> hello
  10 18:00 < dtchen> ok, hi everyone, tonight we'll be covering the topics listed at https://wiki.ubuntu.com/Packaging/Training/Logs/2009-08-28
  11 18:00 -!- {zEr0-x} [n={zEr0-x}@200.14.236.146] has left #ubuntu-classroom ["Leaving"]
  12 18: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
  13 18:01 < dtchen> for those without access to the wiki currently, here's the agendum:
  14 18:01 < dtchen> # Pedigree of Linux audio
  15 18:01 < dtchen> # Modern sound architecture for x86 laptops/netbooks
  16 18:01 < dtchen> # Triaging audio bugs using Launchpad
  17 18:01 < dtchen> # Common problem(symptom)s and their resolutions/workarounds
  18 18:01 < dtchen> # What's in store for Karmic and Karmic+1
  19 18:01 -!- W2IBC [n=W2IBC@c-98-222-160-119.hsd1.in.comcast.net] has joined #ubuntu-classroom
  20 18:01 -!- stefg [n=stefg@g229048015.adsl.alicedsl.de] has joined #ubuntu-classroom
  21 18:01 < dtchen> i'd like to make this session as interactive as possible, so please feel free to ask questions in #ubuntu-classroom-chat
  22 18:02 < dtchen> ok, let's dive in
  23 18:02 < dtchen> Paraphrasing, ALSA began life as a GPL alternative to the languishing
  24 18:02 < dtchen> OSS 3.x. From the onset, it was clearly designed to place only driver
  25 18:02 < dtchen> and necessary core bits in kernelspace; the more complex and extensible
  26 18:02 < dtchen> parts would be in userspace.
  27 18:04 < 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;
  28                 other OSes like the BSDs use some parts of its current version, 4.x, and Solaris has its own "fork" of 4.x.
  29 18:05 -!- thisfred_ [n=thisfred@c-68-34-107-76.hsd1.md.comcast.net] has quit ["Freddie's on the corner now"]
  30 18:05 < 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
  31                 a resource perspective, given upstreams were focusing on it.
  32 18:06 -!- Hew [n=hew@ubuntu/member/hew] has joined #ubuntu-classroom
  33 18:06 -!- croppa [n=stuart@135.27.233.220.static.exetel.com.au] has quit [Read error: 104 (Connection reset by peer)]
  34 18:06 < dtchen> Briefly, i'll describe the modern sound architecture on an Ubuntu release. Perhaps an ASCII diagram helps:
  35 18:07 < dtchen> using the analog of a stack, it looks something akin to,
  36 18:07 < dtchen> - Rhythmbox -
  37 18:07 < dtchen> - GStreamer -
  38 18:07 < dtchen> - PulseAudio -
  39 18:07 < dtchen> - ALSA (-lib, userspace) -
  40 18:08 < dtchen> - ALSA (linux, kernelspace) -
  41 18:08 < dtchen> - hardware -
  42 18:08 -!- Chaser__ [n=Kiran@82-47-206-232.cable.ubr02.wake.blueyonder.co.uk] has joined #ubuntu-classroom
  43 18: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"
  44 18:09 < 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
  45 18:09 < dtchen> the most difficult parts to debug tend to be lower in the stack, e.g., hardware through PulseAudio
  46 18:10 -!- croppa [n=stuart@135.27.233.220.static.exetel.com.au] has joined #ubuntu-classroom
  47 18:10 < 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.
  48 18:11 -!- arvind_khadri [n=arvind@unaffiliated/arvind-khadri/x-2237230] has quit [Read error: 60 (Operation timed out)]
  49 18:11 < 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
  50 18:11 < dtchen> (https://launchpad.net/~ubuntu-audio-dev/+archive/ppa)
  51 18:11 < dtchen> Now that Karmic is in Feature Freeze, it is more important than ever to track that PPA closely.
  52 18:12 < dtchen> 18:10 < Out_Cold> so were do OSS plugins fit in for the stack?
  53 18:12 < dtchen> It depends which OSS plugins Out_Cold's referring to.
  54 18:13 -!- croppa [n=stuart@135.27.233.220.static.exetel.com.au] has quit [Remote closed the connection]
  55 18:13 < maco> <Out_Cold> alsa-oss
  56 18:13 < dtchen> For instance, ALSA itself offers an older OSS compatibility option via two loadable kernel modules, snd-oss-pcm and snd-oss-mixer
  57 18:14 < dtchen> Sorry, that would be snd-pcm-oss and snd-mixer-oss
  58 18:14 < dtchen> Those two modules are loaded by default in Ubuntu and supported remixes to make accessibility (a11y) programs work more smoothly
  59 18:15 -!- DKcross [n=dk@190.87.242.134] has quit [Client Quit]
  60 18:15 < dtchen> (I'll cover that bit toward the end of this discussion.)
  61 18:15 < maco> looks like no further questions
  62 18:15 < dtchen> Having snd-{pcm,mixer}-oss loaded gives userspace /dev/dsp*, /dev/mixer*, /dev/audio*, and other OSS-provided devices.
  63 18:16 < 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.
  64 18:16 -!- bcurtiswx [n=bcurtisw@ubuntu/member/bcurtiswx] has joined #ubuntu-classroom
  65 18:17 -!- bdmurray [n=bdmurray@ns.outflux.net] has joined #ubuntu-classroom
  66 18:17 < bcurtiswx> ok sorry for the delay
  67 18:17 < bcurtiswx> have we started?
  68 18: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
  69                 popular programs.
  70 18:18 -!- limcore [n=limcore@acew245.neoplus.adsl.tpnet.pl] has joined #ubuntu-classroom
  71 18:18 < dtchen> (On the horizon is something called OSSp; we'll cover that briefly toward the end.)
  72 18:18 < limcore> hello
  73 18:20 < 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
  74                 them through ALSA.
  75 18:20 < dtchen> (the same holds for all wrappers, OSSp notwithstanding)
  76 18:20 -!- croppa [n=stuart@135.27.233.220.static.exetel.com.au] has joined #ubuntu-classroom
  77 18:20 < dtchen> So, that should cover Out_Cold's question.
  78 18:20 < andresmujica> stefg: any plans to have a (well needed) system wide EQ in the near future?
  79 18:20 < Out_Cold> ty
  80 18:21 < 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
  81                 are on the pulseaudio-discuss mailing list.
  82 18:22 < dtchen> (We're not really considering LADPSA at this point to be "eq".)
  83 18:22 -!- micahg [n=micah@DHCP-192-111.onshore.com] has joined #ubuntu-classroom
  84 18:22 < dtchen> Any further questions?
  85 18:22 -!- micahg [n=micah@DHCP-192-111.onshore.com] has left #ubuntu-classroom ["Leaving."]
  86 18:22 < maco> <limcore> so, pulse audio fails in multi users scenario.   can we do something about this
  87 18:23 < dtchen> That question needs more detail/context. Are we talking multiseat?
  88 18: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
  89 18:24 < dtchen> PulseAudio has plans for multiseat, yes, but they will not land for Fedora 12, Ubuntu Karmic, etc.
  90 18: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)
  91 18:25 < 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" ?
  92 18:25 < dtchen> limcore: it's possible now, yes. It's not trivial using PA, fairly trivial using ALSA directly, but neither option is ideal.
  93 18:26 < limcore> PA is the ideal solution / the goal for ubuntu right?
  94 18:26 < dtchen> ok, i have a lot more background to cover before we can get to triaging, so let's continue.
  95 18:26 < dtchen> (PA is the upstream momentum, so that's Ubuntu's momentum currently.)
  96 18:27 < dtchen> Bringing the discussion back to triaging sound bugs, what we see a lot of are:
  97 18:27 < dtchen> 0. sound muted bugs
  98 18:27 < dtchen> 1. audio anomaly (crackling, popping) bugs
  99 18:27 < dtchen> 2. general infrastructure bugs
 100 18:28 < dtchen> To understand how these three major classes of bugs have arisen, it's useful to look at current commodity (consumer) laptops and netbooks.
 101 18:29 < dtchen> There are two major audio specifications for laptops and netbooks: AC'97 and High Definition Audio (Azalia).
 102 18:30 -!- arvind_khadri [n=arvind@unaffiliated/arvind-khadri/x-2237230] has joined #ubuntu-classroom
 103 18:30 < dtchen> AC'97 was implemented by many OEMs, perhaps the most popular being the Creative/Sigmatel combination of Live! and Audigy families
 104 18:31 < 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
 105                 Audio (rev a1), is pretty useless
 106 18:32 < 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
 107                 implementing them correctly on every OS.
 108 18:33 < Out_Cold> lspci -v
 109 18:33 < stefg> aplay -l
 110 18:34 < dtchen> For modern laptops and netbooks, we're dealing essentially with HDA codecs and controllers, and that brings new classes of headaches.
 111 18:35 -!- kermiac [n=kermiac@d58-111-220-231.mas4.nsw.optusnet.com.au] has quit [Read error: 54 (Connection reset by peer)]
 112 18:35 < dtchen> One of the reasons for so many regressions between Ubuntu Gutsy and Ubuntu Intrepid was the tightening of codec enforcement.
 113 18:35 -!- kermiac_ [n=kermiac@d58-111-220-231.mas4.nsw.optusnet.com.au] has joined #ubuntu-classroom
 114 18:35 -!- Keiffer [n=mIRCuser@unaffiliated/jbauer] has joined #ubuntu-classroom
 115 18: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,
 116                 sound/pci/hda/patch_*.c)
 117 18:36 -!- Keiffer [n=mIRCuser@unaffiliated/jbauer] has left #ubuntu-classroom []
 118 18:36 < dtchen> Further regressions between Intrepid and Jaunty, e.g., internal microphones not working, have been caused by an infrastructure extension
 119 18:37 < 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.
 120 18:37 < dtchen> (e.g., when you insert headphones, your laptop's internal speakers mute)
 121 18:38 -!- kermiac_ is now known as kermiac
 122 18:38 < dtchen> So, now i'll cover the process from cold boot to GNOME session log in for Ubuntu Jaunty.
 123 18:39 < 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.
 124 18:40 < 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
 125                 sound, and continue on your merry way.
 126 18:41 < 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.
 127 18:41 < dtchen> Here's how the ALSA driver works:
 128 18:42 < dtchen> udev will match the modalias for your vendor and device and load the appropriate codec and controller kernel modules
 129 18:43 < 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)
 130 18:43 -!- goshawk [n=quassel@93-34-51-123.ip48.fastwebnet.it] has joined #ubuntu-classroom
 131 18:43 < dtchen> once the specific match is made, the appropriate patch path for your HDA codec is used
 132 18:45 -!- popey [n=alan@ubuntu/member/pdpc.gold.popey] has joined #ubuntu-classroom
 133 18:45 < 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
 134                 the command line (e.g., model=foo) or there's a hard-coded model quirk in the driver source itself
 135 18:45 < dtchen> essentially, the order is always:
 136 18:45 < dtchen> 0. use passed quirk
 137 18:45 < dtchen> 1. use driver source quirk
 138 18:45 < dtchen> 2. use existing verb table state
 139 18:46 < dtchen> Note that (2) does not imply that the codec was correctly configured!
 140 18:46 < dtchen> (the driver has no way to know if what exists is correct)
 141 18:47 < 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.
 142 18:47 -!- DarwinSurvivor [n=DarwinSu@142.232.134.9] has joined #ubuntu-classroom
 143 18:48 < dtchen> you need to load snd-hwdep to use hda-verb
 144 18:48 < maco> dtchen: glossary request: <limcore> what is this "verb"
 145 18:48 < dtchen> verb tables are essentially "initial states"
 146 18:48 < dtchen> aka "set this pin to route here"
 147 18:49 < dtchen> the HDA specification has a whole list of verbs/commands
 148 18:50 < dtchen> Now, we can move on to the heart of the discussion, which is triaging
 149 18:50 < limcore> and each sound card + main board  pair  needs some proper setup "verb"?
 150 18:50 < zyb> verb from german Verbindung =Connection ?
 151 18:50 < bcurtiswx> questions in #ubuntu-classroom-chat please
 152 18:50 < dtchen> let's return to the list above:
 153 18:50 < dtchen> 18:27 < dtchen> 0. sound muted bugs
 154 18:50 < dtchen> 18:27 < dtchen> 1. audio anomaly (crackling, popping) bugs
 155 18:50 < dtchen> 18:27 < dtchen> 2. general infrastructure bugs
 156 18:51 -!- Keiffer [n=mIRCuser@unaffiliated/jbauer] has joined #ubuntu-classroom
 157 18:51 < dtchen> The first thing to remember when you're triaging sound bugs is that you may be dealing with multiple parts of the stack:
 158 18:51 -!- Irssi: Pasting 6 lines to #ubuntu-classroom. Press Ctrl-K if you wish to do this or Ctrl-C to cancel.
 159 18:51 < dtchen> 18:07 < dtchen> - Rhythmbox -
 160 18:51 < dtchen> 18:07 < dtchen> - GStreamer -
 161 18:51 < dtchen> 18:07 < dtchen> - PulseAudio -
 162 18:51 < dtchen> 18:07 < dtchen> - ALSA (-lib, userspace) -
 163 18:51 < dtchen> 18:08 < dtchen> - ALSA (linux, kernelspace) -
 164 18:51 < dtchen> 18:08 < dtchen> - hardware -
 165 18:51 -!- Keiffer [n=mIRCuser@unaffiliated/jbauer] has quit [SendQ exceeded]
 166 18:52 < dtchen> Realising that, the first action is to identify which part(s) of the stack are pertinent
 167 18:53 < dtchen> After identifying which parts of the stack are pertinent, open a task for each portion of the stack
 168 18:53 < dtchen> for simplicity, i'll use the following source packages:
 169 18:53 < dtchen> kernelspace/driver -> linux
 170 18:53 < dtchen> userspace/-lib -> alsa-lib or alsa-plugins
 171 18:54 < dtchen> the rest are self-explanatory, so let's focus on how to differentiate between linux, alsa-lib, and alsa-plugins
 172 18:54 < dtchen> first of all, please don't triage bugs against alsa-driver when you see them opened by apport
 173 18:54 < dtchen> instead, please migrate them to linux
 174 18:55 < 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
 175                 in the modprobe.d conffiles associated with ALSA (linux-sound-base and/or alsa-base)
 176 18:56 < dtchen> so, a typical work flow might be:
 177 18:56 < dtchen> user A: my sound doesn't work!
 178 18:56 < dtchen> brave triager: please file a bug using "ubuntu-bug alsa-base"
 179 18:56 < dtchen> user A: ok, see bug #7000000
 180 18:57 < dtchen> brave triager: ok, i'm moving bug #7000000 to affect linux instead of alsa-driver
 181 18:57 < dtchen> ok, with that covered, let's cover the easiest part first:
 182 18:58 < dtchen> alsa-plugins bugs are ones like "Skype didn't work until I downloaded V2.1"
 183 18:58 < dtchen> or "OpenArena explodes when I use PulseAudio" (thanks, fta)
 184 18:59 < dtchen> or "32-bit Adobe Flash on my 64-bit machine makes a spoo noise, and my cat died"
 185 18:59 < dtchen> In other words, alsa-plugins are ones where the PulseAudio reroute is clearly to blame
 186 19:00 < dtchen> cf. /usr/share/alsa/pulse*
 187 19:00 < dtchen> please note that Kubuntu and Xubuntu don't use PA by default, so they're fairly unique to Ubuntu, Edubuntu, Ubuntu Studio, ...
 188 19:01 < maco> <limcore> where is PA reroute to blame?  are there some tools to show exact patch of sound like  app --> allegro -> alsa --> PA --> alsa and that allow me to for
 189               example dump the sound stream at given point to see who messes up?
 190 19:01 < maco> dtchen: er...ubuntu studio doesnt use PA either. its jack, remember?
 191 19:02 < dtchen> there's nothing quite like what limcore alluded to
 192 19:02 < dtchen> performing a "tracepath" or "traceroute" of audio is fairly labour-intensive ATM
 193 19:03 < dtchen> the PA reroute can be identified as the culprit in SOME instances by using ALSA directly instead of PA
 194 19:04 < dtchen> e.g., using "arecord -twav foo.wav" results in horrible distortion, but "arecord -Dplug:front:0 -twav foo.wav" is quite clear
 195 19:04 < dtchen> in the first instance, arecord uses the default device, which routes through PA; in the second instance, arecord uses alsa-lib's front virtual device on card 0,
 196                 bypassing PA altogether
 197 19:05 -!- SiDi [i=54669719@gateway/web/freenode/x-kmgkecdzlbupmnan] has quit [Ping timeout: 180 seconds]
 198 19:05 < dtchen> maco: JACK is one component shipped in Ubuntu Studio. PA is still present.
 199 19:06 < dtchen> alsa-lib bugs are more subtle but tend to be more catastrophic
 200 19:07 < dtchen> e.g., bug 412677
 201 19:07 -!- greg-g [i=greg@ubuntu/member/greg-g] has joined #ubuntu-classroom
 202 19:08 < bcurtiswx> ubot4: Launchpad bug 412677 in alsa-lib "pulseaudio crashed with SIGFPE in snd_pcm_mmap_begin()" [Medium,Triaged] https://launchpad.net/bugs/412677
 203 19:08 < bcurtiswx> :D
 204 19:08 < dtchen> in that bug, it's not altogether clear whether the driver should be enforcing a minimum buffer_size or whether the userspace library should refuse to return
 205                 mmapped region
 206 19:09 < dtchen> neither is ideal, but the crash is difficult to trigger, and so in the context for Karmic, we'll simply propagate the error back up to PA, which will try again
 207 19:10 < DarwinSurvivor> is there any way to make the permissions-selector-list wider? I can't read 3/4 of the permissions!
 208 19:10 < DarwinSurvivor> oops, wrong channel :( , sorry
 209 19:11 < dtchen> linux bugs are good defaults, which is why alsa-driver and linux tend to end up with most bugs
 210 19:11 -!- blueyed_ [n=daniel@e181238099.adsl.alicedsl.de] has joined #ubuntu-classroom
 211 19:11 -!- ahe [n=ahe@dslb-088-065-029-215.pools.arcor-ip.net] has quit ["Ex-Chat"]
 212 19:11 < maco> <limcore> ok so how to test if my game (say OpenArena) has sound problems because of PA or alsa kernel driver?   killall pulseaudio and restart my game, or something
 213               more clever?  Please present the commands one should enter to test
 214 19:11 < dtchen> linux bugs are almost always restricted to hardware-enablement, e.g., "my speakers don't mute when I insert headphones unless I pass model=foobar"
 215 19:12 < dtchen> limcore: generally you'll want to identify whether it's alsa-plugins or PA, not linux or PA
 216 19:13 < dtchen> if it's linux, you'll see the symptoms regardless whether ALSA directly (no PA) or PA is used
 217 19:13 < dtchen> i think what you meant to ask is "how do i disable PA to test whether it's to blame?"
 218 19:13 < dtchen> in that case, you can do the following:
 219 19:14 < dtchen> echo autospawn = no|tee -a ~/.pulse/client.conf
 220 19:14 < dtchen> killall pulseaudio
 221 19:15 < dtchen> so now that we have a better idea of how to assign tasks to the audio bugs, we can consider the symptoms themselves
 222 19:16 -!- itnet7 [n=itnet7@ubuntu/member/itnet7] has joined #ubuntu-classroom
 223 19:16 -!- stefg [n=stefg@g229048015.adsl.alicedsl.de] has quit ["ChatZilla 0.9.85 [Firefox 3.0.13/2009080315]"]
 224 19:16 < dtchen> all Linux distributions using ALSA face the same classes of sound bugs, so a few of us prototyped a shell script to cull as much relevant information as possible
 225 19:17 < dtchen> it's now maintained upstream at http://www.alsa-project.org/alsa-info.sh as a bash script, but i understand there's movement at Canonical to remove the cruft in it
 226 19:17 < dtchen> also, to avoid having to fetch alsa-info.sh each time, mdz added apport hooks to accomplish a subset of the functions
 227 19:18 < dtchen> if you feel like contributing, a good place to start is by porting the functionality to alsa-base's and linux's apport hooks
 228 19:19 < dtchen> let's review what we've covered
 229 19:19 < dtchen> first, identify which part(s) of the audio stack are involved. then, open tasks in the bug.
 230 19:20 < bcurtiswx> andresmujica: dtchen: any plans to develop a symptom based apport hook?
 231 19:20 < dtchen> second, if the user has not already contributed information using ubuntu-bug, apport-collect, or the alsa-info.sh script, then ask for that information.
 232 19:20 < dtchen> andresmujica: i'd love to see others help there
 233 19:21 -!- openweek2 [i=29f92438@gateway/web/freenode/x-uazdprkfotfpwuxd] has joined #ubuntu-classroom
 234 19:22 < dtchen> any questions regarding basic sound triaging? we'll continue shortly if there aren't any.
 235 19:22 -!- openweek2 [i=29f92438@gateway/web/freenode/x-uazdprkfotfpwuxd] has quit [Client Quit]
 236 19:22 < andresmujica> (18:20:38) kermiac: so should i run the "alsa-info.sh" script even though I have used apport to collect the relevant info for my bug report?
 237 19:22 -!- sputnik [n=sputnik@guest.clifton.gw.tagonline.com] has quit [Read error: 110 (Connection timed out)]
 238 19:22 < dtchen> kermiac: there's generally no need to; if there is, someone will ask for it
 239 19:23 < dtchen> (where the someone is generally someone on the kernel team, or me, or upstream)
 240 19:23 < dtchen> ok, so let's discuss symptoms. remember the three major classes:
 241 19:23 < dtchen> 18:27 < dtchen> 0. sound muted bugs
 242 19:23 < dtchen> 18:27 < dtchen> 1. audio anomaly (crackling, popping) bugs
 243 19:23 < dtchen> 18:27 < dtchen> 2. general infrastructure bugs
 244 19:24 < dtchen> (0) is pretty straightforward from a triaging perspective
 245 19:25 < dtchen> look at the Card*.Amixer.values.txt in the bug attachment
 246 19:25 < dtchen> or the relevant section in the alsa-info.txt
 247 19:25 -!- IoFran [n=IoFran@189.231.25.60] has quit [Read error: 104 (Connection reset by peer)]
 248 19:26 < dtchen> because there's not one common set of mixer elements, you just have to learn which ones are important based on the codec
 249 19:26 -!- IoFran [n=IoFran@189.231.25.60] has joined #ubuntu-classroom
 250 19:26 < dtchen> BTW, mapping mixer elements to codecs is highly useful; a wiki page could be a prelim DB
 251 19:27 -!- Chaser__ [n=Kiran@82-47-206-232.cable.ubr02.wake.blueyonder.co.uk] has quit [Connection timed out]
 252 19:27 < maco> you mean saying things like how on my laptop the headphones are actually called Surround?
 253 19:27 < dtchen> in general, you want to look at 'Master', 'PCM', 'Wave', 'Front', 'Surround', 'Headphone', 'Speaker'
 254 19:27 -!- blueyed [n=daniel@e181231254.adsl.alicedsl.de] has quit [Read error: 110 (Connection timed out)]
 255 19:27 < dtchen> note that not all codecs will have all (or any!) of those elements
 256 19:28 < dtchen> in upstream-speak, it's the mixer confusion, and it's one thing that PA is addressing via another mixer abstraction layer
 257 19:29 < dtchen> any/all of the playback toggles and/or levels for 'Master', 'PCM', 'Wave', 'Front', 'Surround', 'Headphone', 'Speaker' may be set to zero and/or mute
 258 19:29 < dtchen> in that case, ask for them to be unmuted and raised
 259 19:29 < dtchen> e.g., "I see your PCM is set to zero and muted; please see if raising the level and unmuting results in audible sound"
 260 19:30 -!- mimor [n=mimor@78-21-32-130.access.telenet.be] has quit [Read error: 60 (Operation timed out)]
 261 19:30 < dtchen> now for the fun part: how does one decide whether it's PA or alsa-utils?
 262 19:30 -!- Keiffer [n=mIRCuser@unaffiliated/jbauer] has joined #ubuntu-classroom
 263 19:31 < dtchen> note that PA starts on session login, so if the person reboots but does not log in via GDM (instead using tty1, ctrl+alt+F1), it should be easy to pinpoint whether
 264                 PA is restoring incorrect levels
 265 19:33 < dtchen> e.g., login on tty, look at alsamixer
 266 19:33 < dtchen> tty1*
 267 19:33 -!- joaopinto [n=ptjoaopi@nat/ibm/x-drxhhfgacfkifrsq] has quit [Remote closed the connection]
 268 19:34 -!- jMyles [n=justin@user-160u2bh.cable.mindspring.com] has quit [Remote closed the connection]
 269 19:34 < andresmujica>  zyb: But what if the important mixer isn't even displayed, because its "chan1"?  or is that in the files anyway?
 270 19:34 < maco> oh
 271 19:34 < maco> (wrong window)
 272 19:34 < dtchen> zyb: please clarify to what chan1 refers
 273 19:35 -!- Keiffer [n=mIRCuser@unaffiliated/jbauer] has quit []
 274 19:36 < zyb> Thats it! One Name meaningless to all but the developer that chose it
 275 19:36 < dtchen> zyb: as of Jaunty, by default alsamixer and amixer expose the ALSA-lib view, not the PA view
 276 19:37 < zyb> and therefore not supported by any program
 277 19:37 < dtchen> in Intrepid, there was some confusion, so one needed to use alsamixer -Dhw:0
 278 19:37 < maco> dtchen: i think he means what if there's some mixer element that is the issue but isnt named PCM or Front or one of those common ones...how do you know it's the
 279               issue? and what if mixers dont show it by default? (since the gui mixers only show "important" ones by default)
 280 19:37 < dtchen> zyb: then someone needs to stab repeatedly until it's fixed in the source code
 281 19:37 -!- komputes [n=komputes@unaffiliated/komputes] has quit [Remote closed the connection]
 282 19:38 < dtchen> zyb: there's a lot of trial and error in debugging the new codecs
 283 19:38 < dtchen> sometimes even older ones, e.g., the latest alsa-utils upload
 284 19:39 < dtchen> any further questions?
 285 19:40 < bcurtiswx> nothing so far dtchen
 286 19:40 < bcurtiswx> is there a wiki page with all of this valuable information?
 287 19:41 < dtchen> ok, moving on to (1), which is almost always linux and lower in the stack, i.e., you're looking at crack hardware and insufficient driver workarounds
 288 19:41 < dtchen> note that other peripherals, like the bus latency of video devices, can affect (1)
 289 19:43 < dtchen> i'm about to submit a patch against our linux source that should help in one aspect by increasing the default preallocation buffer size to 2 MB instead of 64 KB
 290 19:43 < dtchen> other distributions have done similarly, choosing something between 1 MB and 2 MB inclusive
 291 19:44 < dtchen> rtkit in Karmic will also help if the necessary linux patches are merged (they're being discussed ATM)
 292 19:44 < dtchen> these symptoms are less prevalent in Karmic but fairly evident using PA in Jaunty
 293 19:44 < maco> #define rtkit?
 294 19:45 < dtchen> "apt-cache show rtkit"
 295 19:45 < maco> oh its a package. ok
 296 19:45 < dtchen> any questions on debugging (1)?
 297 19:46 -!- komputes [n=komputes@unaffiliated/komputes] has joined #ubuntu-classroom
 298 19:46 < andresmujica> is this related to that ? pulseaudio[4959]: alsa-sink.c: Increasing minimal latency to 76,00 ms
 299 19:47 < dtchen> andresmujica: yes, it is related
 300 19:47 < dtchen> essentially your hardware requires a higher watermark, so PA adjusts for you and will buffer more
 301 19:47 < dtchen> if it holds steady, it will attempt to decrease
 302 19:47 < andresmujica> VoIP suffers A LOT from this... and with the VoIP high CPU requirements for VoIP codecs, i'm worried about VoIP in Linux...
 303 19:48 < dtchen> well, for people who MUST use Skype, use the new Skype with PA support.
 304 19:48 < andresmujica> i mean corporate VoIP ...
 305 19:48 < andresmujica> not skype..
 306 19:49 < andresmujica> but that's a different story..
 307 19:49 < dtchen> andresmujica: there are workarounds, like disabling glitch-free and flatvol
 308 19:49 < dtchen> it's really hard to anticipate all sorts of broken hardware combinations
 309 19:50 < andresmujica> so PA shows more clearly the HW problems not detected previously by alsa?
 310 19:50 < maco> yeah
 311 19:51 -!- nizarus [n=nizarus@ubuntu/member/nizarus] has quit ["bye bye"]
 312 19:51 < dtchen> no, they were always there in ALSA
 313 19:51 < dtchen> i really can't emphasise that enough
 314 19:51 -!- arvind_khadri [n=arvind@unaffiliated/arvind-khadri/x-2237230] has quit [Read error: 104 (Connection reset by peer)]
 315 19:51 < dtchen> e.g., it's not as if that fpe bug would not have existed if PA hadn't existed :-)
 316 19:52 < maco> dtchen: but whether they were *noticed* or not...?
 317 19:53 < dtchen> ok, so to cover (2): general infrastructure bugs are ones like ia32-libs/alsa-plugins/pulseaudio, or using PA on Kubuntu/Xubuntu/Ubuntu Studio
 318 19:53 -!- kamusin [i=bec4161a@gateway/web/freenode/x-ierlwyrnzyshdjcv] has quit ["Page closed"]
 319 19:53 -!- goshawk [n=quassel@93-34-51-123.ip48.fastwebnet.it] has quit [Read error: 110 (Connection timed out)]
 320 19:53 < dtchen> these are situations where volume controls are not present in the default distro
 321 19:54 < dtchen> these are mostly Low- or Wishlist-priority bugs
 322 19:54 < dtchen> the obvious usability perspective is important, but people need to step in to help resolve those
 323 19:55 -!- limcore [n=limcore@acew245.neoplus.adsl.tpnet.pl] has quit [Remote closed the connection]
 324 19:55 < dtchen> lastly, what's in store for Karmic{,+1} :
 325 19:56 < dtchen> it's important to track the ~ubuntu-audio-dev PPA and continue to file bugs
 326 19:56 < dtchen> for the purpose of PulseAudio, it is legitimate to file bugs UNTIL Karmic's release against the PPA version
 327 19:57 < dtchen> at the point of Karmic's release in October, bugs filed against the PPA version of PA will be Invalidated
 328 19:58 < dtchen> it's important to note that this policy is ONLY valid for PA in Karmic and ONLY while Karmic is open for development
 329 20:00 < dtchen> currently, there are a couple of high priority bugs for PA: session state confusion, i.e., volume being muted on session login
 330 20:00 < dtchen> also, device enumeration
 331 20:00 < dtchen> any questions in conclusion?
 332 20:02 -!- jMyles [n=justin@pool-96-238-100-111.pghkny.east.verizon.net] has joined #ubuntu-classroom
 333 20:02 < andresmujica> what about upstreaming PA bugs ?  is there a policy for that? when it should be done?
 334 20:03 < dtchen> andresmujica: users tend to do that; distros tend to use pulseaudio-discuss
 335 20:04 < zyb> something about karmic+1? Was mentioned at beginning
 336 20:04 < dtchen> andresmujica: i see nothing wrong with encouraging individual users to do so, but many of our changes were Ubuntu-specific
 337 20:04 -!- Andphe [n=Andphe@190.157.29.71] has left #ubuntu-classroom ["Leaving."]
 338 20:05 < dtchen> zyb: there's a lot on the plate for +1 : native multiarch, power-down configurations, "tracing sound routes"
 339 20:07 < zyb> tracing like traceroute? cool!!
 340 20:07 < dtchen> bcurtiswx: no, but one of the reasons i opted for a lot of background info is to enable wikifying the info
 341 20:08 < dtchen> anyhow, if there are no further questions, i'm happy to head out. thanks, everyone!
 342 20:08 < kermiac> thanks dtchen
 343 20:08 < andresmujica> thanks to you dtchen!! thanks for your time!
 344 20:09 < bcurtiswx> dtchen: cool thx


CategoryPackaging

Packaging/Training/Logs/2009-08-28 (last edited 2009-08-29 00:12:14 by c-24-126-105-207)