<> '''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 ---- {{{#!irc 17:56 -!- Irssi: #ubuntu-classroom: Total of 97 nicks [1 ops, 0 halfops, 0 voices, 96 normal] 17:56 < komputes> hi dtchen ! 17:56 < andresmujica> hi dtchen 17:56 < dtchen> hi 17:56 < dtchen> https://wiki.ubuntu.com/Packaging/Training/Logs/2009-08-28 17:56 -!- Channel #ubuntu-classroom created Sun Nov 26 01:42:45 2006 17:57 -!- SiDi [i=54669719@gateway/web/freenode/x-kmgkecdzlbupmnan] has joined #ubuntu-classroom 17:58 -!- Irssi: Join to #ubuntu-classroom was synced in 110 secs 17:58 < maco> hello 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 18:00 -!- {zEr0-x} [n={zEr0-x}@200.14.236.146] has left #ubuntu-classroom ["Leaving"] 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 18:01 < dtchen> for those without access to the wiki currently, here's the agendum: 18:01 < dtchen> # Pedigree of Linux audio 18:01 < dtchen> # Modern sound architecture for x86 laptops/netbooks 18:01 < dtchen> # Triaging audio bugs using Launchpad 18:01 < dtchen> # Common problem(symptom)s and their resolutions/workarounds 18:01 < dtchen> # What's in store for Karmic and Karmic+1 18:01 -!- W2IBC [n=W2IBC@c-98-222-160-119.hsd1.in.comcast.net] has joined #ubuntu-classroom 18:01 -!- stefg [n=stefg@g229048015.adsl.alicedsl.de] has joined #ubuntu-classroom 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 18:02 < dtchen> ok, let's dive in 18:02 < dtchen> Paraphrasing, ALSA began life as a GPL alternative to the languishing 18:02 < dtchen> OSS 3.x. From the onset, it was clearly designed to place only driver 18:02 < dtchen> and necessary core bits in kernelspace; the more complex and extensible 18:02 < dtchen> parts would be in userspace. 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; other OSes like the BSDs use some parts of its current version, 4.x, and Solaris has its own "fork" of 4.x. 18:05 -!- thisfred_ [n=thisfred@c-68-34-107-76.hsd1.md.comcast.net] has quit ["Freddie's on the corner now"] 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 a resource perspective, given upstreams were focusing on it. 18:06 -!- Hew [n=hew@ubuntu/member/hew] has joined #ubuntu-classroom 18:06 -!- croppa [n=stuart@135.27.233.220.static.exetel.com.au] has quit [Read error: 104 (Connection reset by peer)] 18:06 < dtchen> Briefly, i'll describe the modern sound architecture on an Ubuntu release. Perhaps an ASCII diagram helps: 18:07 < dtchen> using the analog of a stack, it looks something akin to, 18:07 < dtchen> - Rhythmbox - 18:07 < dtchen> - GStreamer - 18:07 < dtchen> - PulseAudio - 18:07 < dtchen> - ALSA (-lib, userspace) - 18:08 < dtchen> - ALSA (linux, kernelspace) - 18:08 < dtchen> - hardware - 18:08 -!- Chaser__ [n=Kiran@82-47-206-232.cable.ubr02.wake.blueyonder.co.uk] has joined #ubuntu-classroom 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" 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 18:09 < dtchen> the most difficult parts to debug tend to be lower in the stack, e.g., hardware through PulseAudio 18:10 -!- croppa [n=stuart@135.27.233.220.static.exetel.com.au] has joined #ubuntu-classroom 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. 18:11 -!- arvind_khadri [n=arvind@unaffiliated/arvind-khadri/x-2237230] has quit [Read error: 60 (Operation timed out)] 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 18:11 < dtchen> (https://launchpad.net/~ubuntu-audio-dev/+archive/ppa) 18:11 < dtchen> Now that Karmic is in Feature Freeze, it is more important than ever to track that PPA closely. 18:12 < dtchen> 18:10 < Out_Cold> so were do OSS plugins fit in for the stack? 18:12 < dtchen> It depends which OSS plugins Out_Cold's referring to. 18:13 -!- croppa [n=stuart@135.27.233.220.static.exetel.com.au] has quit [Remote closed the connection] 18:13 < maco> alsa-oss 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 18:14 < dtchen> Sorry, that would be snd-pcm-oss and snd-mixer-oss 18:14 < dtchen> Those two modules are loaded by default in Ubuntu and supported remixes to make accessibility (a11y) programs work more smoothly 18:15 -!- DKcross [n=dk@190.87.242.134] has quit [Client Quit] 18:15 < dtchen> (I'll cover that bit toward the end of this discussion.) 18:15 < maco> looks like no further questions 18:15 < dtchen> Having snd-{pcm,mixer}-oss loaded gives userspace /dev/dsp*, /dev/mixer*, /dev/audio*, and other OSS-provided devices. 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. 18:16 -!- bcurtiswx [n=bcurtisw@ubuntu/member/bcurtiswx] has joined #ubuntu-classroom 18:17 -!- bdmurray [n=bdmurray@ns.outflux.net] has joined #ubuntu-classroom 18:17 < bcurtiswx> ok sorry for the delay 18:17 < bcurtiswx> have we started? 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 popular programs. 18:18 -!- limcore [n=limcore@acew245.neoplus.adsl.tpnet.pl] has joined #ubuntu-classroom 18:18 < dtchen> (On the horizon is something called OSSp; we'll cover that briefly toward the end.) 18:18 < limcore> hello 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 them through ALSA. 18:20 < dtchen> (the same holds for all wrappers, OSSp notwithstanding) 18:20 -!- croppa [n=stuart@135.27.233.220.static.exetel.com.au] has joined #ubuntu-classroom 18:20 < dtchen> So, that should cover Out_Cold's question. 18:20 < andresmujica> stefg: any plans to have a (well needed) system wide EQ in the near future? 18:20 < Out_Cold> ty 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 are on the pulseaudio-discuss mailing list. 18:22 < dtchen> (We're not really considering LADPSA at this point to be "eq".) 18:22 -!- micahg [n=micah@DHCP-192-111.onshore.com] has joined #ubuntu-classroom 18:22 < dtchen> Any further questions? 18:22 -!- micahg [n=micah@DHCP-192-111.onshore.com] has left #ubuntu-classroom ["Leaving."] 18:22 < maco> so, pulse audio fails in multi users scenario. can we do something about this 18:23 < dtchen> That question needs more detail/context. Are we talking multiseat? 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 18:24 < dtchen> PulseAudio has plans for multiseat, yes, but they will not land for Fedora 12, Ubuntu Karmic, etc. 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) 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" ? 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. 18:26 < limcore> PA is the ideal solution / the goal for ubuntu right? 18:26 < dtchen> ok, i have a lot more background to cover before we can get to triaging, so let's continue. 18:26 < dtchen> (PA is the upstream momentum, so that's Ubuntu's momentum currently.) 18:27 < dtchen> Bringing the discussion back to triaging sound bugs, what we see a lot of are: 18:27 < dtchen> 0. sound muted bugs 18:27 < dtchen> 1. audio anomaly (crackling, popping) bugs 18:27 < dtchen> 2. general infrastructure bugs 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. 18:29 < dtchen> There are two major audio specifications for laptops and netbooks: AC'97 and High Definition Audio (Azalia). 18:30 -!- arvind_khadri [n=arvind@unaffiliated/arvind-khadri/x-2237230] has joined #ubuntu-classroom 18:30 < dtchen> AC'97 was implemented by many OEMs, perhaps the most popular being the Creative/Sigmatel combination of Live! and Audigy families 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 Audio (rev a1), is pretty useless 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 implementing them correctly on every OS. 18:33 < Out_Cold> lspci -v 18:33 < stefg> aplay -l 18:34 < dtchen> For modern laptops and netbooks, we're dealing essentially with HDA codecs and controllers, and that brings new classes of headaches. 18:35 -!- kermiac [n=kermiac@d58-111-220-231.mas4.nsw.optusnet.com.au] has quit [Read error: 54 (Connection reset by peer)] 18:35 < dtchen> One of the reasons for so many regressions between Ubuntu Gutsy and Ubuntu Intrepid was the tightening of codec enforcement. 18:35 -!- kermiac_ [n=kermiac@d58-111-220-231.mas4.nsw.optusnet.com.au] has joined #ubuntu-classroom 18:35 -!- Keiffer [n=mIRCuser@unaffiliated/jbauer] has joined #ubuntu-classroom 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, sound/pci/hda/patch_*.c) 18:36 -!- Keiffer [n=mIRCuser@unaffiliated/jbauer] has left #ubuntu-classroom [] 18:36 < dtchen> Further regressions between Intrepid and Jaunty, e.g., internal microphones not working, have been caused by an infrastructure extension 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. 18:37 < dtchen> (e.g., when you insert headphones, your laptop's internal speakers mute) 18:38 -!- kermiac_ is now known as kermiac 18:38 < dtchen> So, now i'll cover the process from cold boot to GNOME session log in for Ubuntu Jaunty. 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. 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 sound, and continue on your merry way. 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. 18:41 < dtchen> Here's how the ALSA driver works: 18:42 < dtchen> udev will match the modalias for your vendor and device and load the appropriate codec and controller kernel modules 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) 18:43 -!- goshawk [n=quassel@93-34-51-123.ip48.fastwebnet.it] has joined #ubuntu-classroom 18:43 < dtchen> once the specific match is made, the appropriate patch path for your HDA codec is used 18:45 -!- popey [n=alan@ubuntu/member/pdpc.gold.popey] has joined #ubuntu-classroom 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 the command line (e.g., model=foo) or there's a hard-coded model quirk in the driver source itself 18:45 < dtchen> essentially, the order is always: 18:45 < dtchen> 0. use passed quirk 18:45 < dtchen> 1. use driver source quirk 18:45 < dtchen> 2. use existing verb table state 18:46 < dtchen> Note that (2) does not imply that the codec was correctly configured! 18:46 < dtchen> (the driver has no way to know if what exists is correct) 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. 18:47 -!- DarwinSurvivor [n=DarwinSu@142.232.134.9] has joined #ubuntu-classroom 18:48 < dtchen> you need to load snd-hwdep to use hda-verb 18:48 < maco> dtchen: glossary request: what is this "verb" 18:48 < dtchen> verb tables are essentially "initial states" 18:48 < dtchen> aka "set this pin to route here" 18:49 < dtchen> the HDA specification has a whole list of verbs/commands 18:50 < dtchen> Now, we can move on to the heart of the discussion, which is triaging 18:50 < limcore> and each sound card + main board pair needs some proper setup "verb"? 18:50 < zyb> verb from german Verbindung =Connection ? 18:50 < bcurtiswx> questions in #ubuntu-classroom-chat please 18:50 < dtchen> let's return to the list above: 18:50 < dtchen> 18:27 < dtchen> 0. sound muted bugs 18:50 < dtchen> 18:27 < dtchen> 1. audio anomaly (crackling, popping) bugs 18:50 < dtchen> 18:27 < dtchen> 2. general infrastructure bugs 18:51 -!- Keiffer [n=mIRCuser@unaffiliated/jbauer] has joined #ubuntu-classroom 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: 18:51 -!- Irssi: Pasting 6 lines to #ubuntu-classroom. Press Ctrl-K if you wish to do this or Ctrl-C to cancel. 18:51 < dtchen> 18:07 < dtchen> - Rhythmbox - 18:51 < dtchen> 18:07 < dtchen> - GStreamer - 18:51 < dtchen> 18:07 < dtchen> - PulseAudio - 18:51 < dtchen> 18:07 < dtchen> - ALSA (-lib, userspace) - 18:51 < dtchen> 18:08 < dtchen> - ALSA (linux, kernelspace) - 18:51 < dtchen> 18:08 < dtchen> - hardware - 18:51 -!- Keiffer [n=mIRCuser@unaffiliated/jbauer] has quit [SendQ exceeded] 18:52 < dtchen> Realising that, the first action is to identify which part(s) of the stack are pertinent 18:53 < dtchen> After identifying which parts of the stack are pertinent, open a task for each portion of the stack 18:53 < dtchen> for simplicity, i'll use the following source packages: 18:53 < dtchen> kernelspace/driver -> linux 18:53 < dtchen> userspace/-lib -> alsa-lib or alsa-plugins 18:54 < dtchen> the rest are self-explanatory, so let's focus on how to differentiate between linux, alsa-lib, and alsa-plugins 18:54 < dtchen> first of all, please don't triage bugs against alsa-driver when you see them opened by apport 18:54 < dtchen> instead, please migrate them to linux 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 in the modprobe.d conffiles associated with ALSA (linux-sound-base and/or alsa-base) 18:56 < dtchen> so, a typical work flow might be: 18:56 < dtchen> user A: my sound doesn't work! 18:56 < dtchen> brave triager: please file a bug using "ubuntu-bug alsa-base" 18:56 < dtchen> user A: ok, see bug #7000000 18:57 < dtchen> brave triager: ok, i'm moving bug #7000000 to affect linux instead of alsa-driver 18:57 < dtchen> ok, with that covered, let's cover the easiest part first: 18:58 < dtchen> alsa-plugins bugs are ones like "Skype didn't work until I downloaded V2.1" 18:58 < dtchen> or "OpenArena explodes when I use PulseAudio" (thanks, fta) 18:59 < dtchen> or "32-bit Adobe Flash on my 64-bit machine makes a spoo noise, and my cat died" 18:59 < dtchen> In other words, alsa-plugins are ones where the PulseAudio reroute is clearly to blame 19:00 < dtchen> cf. /usr/share/alsa/pulse* 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, ... 19:01 < maco> 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 example dump the sound stream at given point to see who messes up? 19:01 < maco> dtchen: er...ubuntu studio doesnt use PA either. its jack, remember? 19:02 < dtchen> there's nothing quite like what limcore alluded to 19:02 < dtchen> performing a "tracepath" or "traceroute" of audio is fairly labour-intensive ATM 19:03 < dtchen> the PA reroute can be identified as the culprit in SOME instances by using ALSA directly instead of PA 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 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, bypassing PA altogether 19:05 -!- SiDi [i=54669719@gateway/web/freenode/x-kmgkecdzlbupmnan] has quit [Ping timeout: 180 seconds] 19:05 < dtchen> maco: JACK is one component shipped in Ubuntu Studio. PA is still present. 19:06 < dtchen> alsa-lib bugs are more subtle but tend to be more catastrophic 19:07 < dtchen> e.g., bug 412677 19:07 -!- greg-g [i=greg@ubuntu/member/greg-g] has joined #ubuntu-classroom 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 19:08 < bcurtiswx> :D 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 mmapped region 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 19:10 < DarwinSurvivor> is there any way to make the permissions-selector-list wider? I can't read 3/4 of the permissions! 19:10 < DarwinSurvivor> oops, wrong channel :( , sorry 19:11 < dtchen> linux bugs are good defaults, which is why alsa-driver and linux tend to end up with most bugs 19:11 -!- blueyed_ [n=daniel@e181238099.adsl.alicedsl.de] has joined #ubuntu-classroom 19:11 -!- ahe [n=ahe@dslb-088-065-029-215.pools.arcor-ip.net] has quit ["Ex-Chat"] 19:11 < maco> 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 more clever? Please present the commands one should enter to test 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" 19:12 < dtchen> limcore: generally you'll want to identify whether it's alsa-plugins or PA, not linux or PA 19:13 < dtchen> if it's linux, you'll see the symptoms regardless whether ALSA directly (no PA) or PA is used 19:13 < dtchen> i think what you meant to ask is "how do i disable PA to test whether it's to blame?" 19:13 < dtchen> in that case, you can do the following: 19:14 < dtchen> echo autospawn = no|tee -a ~/.pulse/client.conf 19:14 < dtchen> killall pulseaudio 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 19:16 -!- itnet7 [n=itnet7@ubuntu/member/itnet7] has joined #ubuntu-classroom 19:16 -!- stefg [n=stefg@g229048015.adsl.alicedsl.de] has quit ["ChatZilla 0.9.85 [Firefox 3.0.13/2009080315]"] 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 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 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 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 19:19 < dtchen> let's review what we've covered 19:19 < dtchen> first, identify which part(s) of the audio stack are involved. then, open tasks in the bug. 19:20 < bcurtiswx> andresmujica: dtchen: any plans to develop a symptom based apport hook? 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. 19:20 < dtchen> andresmujica: i'd love to see others help there 19:21 -!- openweek2 [i=29f92438@gateway/web/freenode/x-uazdprkfotfpwuxd] has joined #ubuntu-classroom 19:22 < dtchen> any questions regarding basic sound triaging? we'll continue shortly if there aren't any. 19:22 -!- openweek2 [i=29f92438@gateway/web/freenode/x-uazdprkfotfpwuxd] has quit [Client Quit] 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? 19:22 -!- sputnik [n=sputnik@guest.clifton.gw.tagonline.com] has quit [Read error: 110 (Connection timed out)] 19:22 < dtchen> kermiac: there's generally no need to; if there is, someone will ask for it 19:23 < dtchen> (where the someone is generally someone on the kernel team, or me, or upstream) 19:23 < dtchen> ok, so let's discuss symptoms. remember the three major classes: 19:23 < dtchen> 18:27 < dtchen> 0. sound muted bugs 19:23 < dtchen> 18:27 < dtchen> 1. audio anomaly (crackling, popping) bugs 19:23 < dtchen> 18:27 < dtchen> 2. general infrastructure bugs 19:24 < dtchen> (0) is pretty straightforward from a triaging perspective 19:25 < dtchen> look at the Card*.Amixer.values.txt in the bug attachment 19:25 < dtchen> or the relevant section in the alsa-info.txt 19:25 -!- IoFran [n=IoFran@189.231.25.60] has quit [Read error: 104 (Connection reset by peer)] 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 19:26 -!- IoFran [n=IoFran@189.231.25.60] has joined #ubuntu-classroom 19:26 < dtchen> BTW, mapping mixer elements to codecs is highly useful; a wiki page could be a prelim DB 19:27 -!- Chaser__ [n=Kiran@82-47-206-232.cable.ubr02.wake.blueyonder.co.uk] has quit [Connection timed out] 19:27 < maco> you mean saying things like how on my laptop the headphones are actually called Surround? 19:27 < dtchen> in general, you want to look at 'Master', 'PCM', 'Wave', 'Front', 'Surround', 'Headphone', 'Speaker' 19:27 -!- blueyed [n=daniel@e181231254.adsl.alicedsl.de] has quit [Read error: 110 (Connection timed out)] 19:27 < dtchen> note that not all codecs will have all (or any!) of those elements 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 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 19:29 < dtchen> in that case, ask for them to be unmuted and raised 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" 19:30 -!- mimor [n=mimor@78-21-32-130.access.telenet.be] has quit [Read error: 60 (Operation timed out)] 19:30 < dtchen> now for the fun part: how does one decide whether it's PA or alsa-utils? 19:30 -!- Keiffer [n=mIRCuser@unaffiliated/jbauer] has joined #ubuntu-classroom 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 PA is restoring incorrect levels 19:33 < dtchen> e.g., login on tty, look at alsamixer 19:33 < dtchen> tty1* 19:33 -!- joaopinto [n=ptjoaopi@nat/ibm/x-drxhhfgacfkifrsq] has quit [Remote closed the connection] 19:34 -!- jMyles [n=justin@user-160u2bh.cable.mindspring.com] has quit [Remote closed the connection] 19:34 < andresmujica> zyb: But what if the important mixer isn't even displayed, because its "chan1"? or is that in the files anyway? 19:34 < maco> oh 19:34 < maco> (wrong window) 19:34 < dtchen> zyb: please clarify to what chan1 refers 19:35 -!- Keiffer [n=mIRCuser@unaffiliated/jbauer] has quit [] 19:36 < zyb> Thats it! One Name meaningless to all but the developer that chose it 19:36 < dtchen> zyb: as of Jaunty, by default alsamixer and amixer expose the ALSA-lib view, not the PA view 19:37 < zyb> and therefore not supported by any program 19:37 < dtchen> in Intrepid, there was some confusion, so one needed to use alsamixer -Dhw:0 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 issue? and what if mixers dont show it by default? (since the gui mixers only show "important" ones by default) 19:37 < dtchen> zyb: then someone needs to stab repeatedly until it's fixed in the source code 19:37 -!- komputes [n=komputes@unaffiliated/komputes] has quit [Remote closed the connection] 19:38 < dtchen> zyb: there's a lot of trial and error in debugging the new codecs 19:38 < dtchen> sometimes even older ones, e.g., the latest alsa-utils upload 19:39 < dtchen> any further questions? 19:40 < bcurtiswx> nothing so far dtchen 19:40 < bcurtiswx> is there a wiki page with all of this valuable information? 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 19:41 < dtchen> note that other peripherals, like the bus latency of video devices, can affect (1) 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 19:43 < dtchen> other distributions have done similarly, choosing something between 1 MB and 2 MB inclusive 19:44 < dtchen> rtkit in Karmic will also help if the necessary linux patches are merged (they're being discussed ATM) 19:44 < dtchen> these symptoms are less prevalent in Karmic but fairly evident using PA in Jaunty 19:44 < maco> #define rtkit? 19:45 < dtchen> "apt-cache show rtkit" 19:45 < maco> oh its a package. ok 19:45 < dtchen> any questions on debugging (1)? 19:46 -!- komputes [n=komputes@unaffiliated/komputes] has joined #ubuntu-classroom 19:46 < andresmujica> is this related to that ? pulseaudio[4959]: alsa-sink.c: Increasing minimal latency to 76,00 ms 19:47 < dtchen> andresmujica: yes, it is related 19:47 < dtchen> essentially your hardware requires a higher watermark, so PA adjusts for you and will buffer more 19:47 < dtchen> if it holds steady, it will attempt to decrease 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... 19:48 < dtchen> well, for people who MUST use Skype, use the new Skype with PA support. 19:48 < andresmujica> i mean corporate VoIP ... 19:48 < andresmujica> not skype.. 19:49 < andresmujica> but that's a different story.. 19:49 < dtchen> andresmujica: there are workarounds, like disabling glitch-free and flatvol 19:49 < dtchen> it's really hard to anticipate all sorts of broken hardware combinations 19:50 < andresmujica> so PA shows more clearly the HW problems not detected previously by alsa? 19:50 < maco> yeah 19:51 -!- nizarus [n=nizarus@ubuntu/member/nizarus] has quit ["bye bye"] 19:51 < dtchen> no, they were always there in ALSA 19:51 < dtchen> i really can't emphasise that enough 19:51 -!- arvind_khadri [n=arvind@unaffiliated/arvind-khadri/x-2237230] has quit [Read error: 104 (Connection reset by peer)] 19:51 < dtchen> e.g., it's not as if that fpe bug would not have existed if PA hadn't existed :-) 19:52 < maco> dtchen: but whether they were *noticed* or not...? 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 19:53 -!- kamusin [i=bec4161a@gateway/web/freenode/x-ierlwyrnzyshdjcv] has quit ["Page closed"] 19:53 -!- goshawk [n=quassel@93-34-51-123.ip48.fastwebnet.it] has quit [Read error: 110 (Connection timed out)] 19:53 < dtchen> these are situations where volume controls are not present in the default distro 19:54 < dtchen> these are mostly Low- or Wishlist-priority bugs 19:54 < dtchen> the obvious usability perspective is important, but people need to step in to help resolve those 19:55 -!- limcore [n=limcore@acew245.neoplus.adsl.tpnet.pl] has quit [Remote closed the connection] 19:55 < dtchen> lastly, what's in store for Karmic{,+1} : 19:56 < dtchen> it's important to track the ~ubuntu-audio-dev PPA and continue to file bugs 19:56 < dtchen> for the purpose of PulseAudio, it is legitimate to file bugs UNTIL Karmic's release against the PPA version 19:57 < dtchen> at the point of Karmic's release in October, bugs filed against the PPA version of PA will be Invalidated 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 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 20:00 < dtchen> also, device enumeration 20:00 < dtchen> any questions in conclusion? 20:02 -!- jMyles [n=justin@pool-96-238-100-111.pghkny.east.verizon.net] has joined #ubuntu-classroom 20:02 < andresmujica> what about upstreaming PA bugs ? is there a policy for that? when it should be done? 20:03 < dtchen> andresmujica: users tend to do that; distros tend to use pulseaudio-discuss 20:04 < zyb> something about karmic+1? Was mentioned at beginning 20:04 < dtchen> andresmujica: i see nothing wrong with encouraging individual users to do so, but many of our changes were Ubuntu-specific 20:04 -!- Andphe [n=Andphe@190.157.29.71] has left #ubuntu-classroom ["Leaving."] 20:05 < dtchen> zyb: there's a lot on the plate for +1 : native multiarch, power-down configurations, "tracing sound routes" 20:07 < zyb> tracing like traceroute? cool!! 20:07 < dtchen> bcurtiswx: no, but one of the reasons i opted for a lot of background info is to enable wikifying the info 20:08 < dtchen> anyhow, if there are no further questions, i'm happy to head out. thanks, everyone! 20:08 < kermiac> thanks dtchen 20:08 < andresmujica> thanks to you dtchen!! thanks for your time! 20:09 < bcurtiswx> dtchen: cool thx }}} ---- CategoryPackaging