| dtchen | cf. /usr/share/alsa/pulse* | 00:00 |
|---|---|---|
| dtchen | please note that Kubuntu and Xubuntu don't use PA by default, so they're fairly unique to Ubuntu, Edubuntu, Ubuntu Studio, ... | 00:00 |
| 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 example dump the sound stream at given point to see who messes up? | 00:01 |
| maco | dtchen: er...ubuntu studio doesnt use PA either. its jack, remember? | 00:01 |
| dtchen | there's nothing quite like what limcore alluded to | 00:02 |
| dtchen | performing a "tracepath" or "traceroute" of audio is fairly labour-intensive ATM | 00:02 |
| dtchen | the PA reroute can be identified as the culprit in SOME instances by using ALSA directly instead of PA | 00:03 |
| dtchen | e.g., using "arecord -twav foo.wav" results in horrible distortion, but "arecord -Dplug:front:0 -twav foo.wav" is quite clear | 00: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 | 00:04 |
| dtchen | maco: JACK is one component shipped in Ubuntu Studio. PA is still present. | 00:05 |
| dtchen | alsa-lib bugs are more subtle but tend to be more catastrophic | 00:06 |
| dtchen | e.g., bug 412677 | 00:07 |
| bcurtiswx | ubot4: Launchpad bug 412677 in alsa-lib "pulseaudio crashed with SIGFPE in snd_pcm_mmap_begin()" [Medium,Triaged] https://launchpad.net/bugs/412677 | 00:08 |
| bcurtiswx | :D | 00: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 | 00:08 |
| 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 | 00:09 |
| DarwinSurvivor | is there any way to make the permissions-selector-list wider? I can't read 3/4 of the permissions! | 00:10 |
| DarwinSurvivor | oops, wrong channel :( , sorry | 00:10 |
| dtchen | linux bugs are good defaults, which is why alsa-driver and linux tend to end up with most bugs | 00: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 more clever? Please present the commands one should enter to test | 00: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" | 00:11 |
| dtchen | limcore: generally you'll want to identify whether it's alsa-plugins or PA, not linux or PA | 00:12 |
| dtchen | if it's linux, you'll see the symptoms regardless whether ALSA directly (no PA) or PA is used | 00:13 |
| dtchen | i think what you meant to ask is "how do i disable PA to test whether it's to blame?" | 00:13 |
| dtchen | in that case, you can do the following: | 00:13 |
| dtchen | echo autospawn = no|tee -a ~/.pulse/client.conf | 00:14 |
| dtchen | killall pulseaudio | 00:14 |
| dtchen | so now that we have a better idea of how to assign tasks to the audio bugs, we can consider the symptoms themselves | 00:15 |
| 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 | 00:16 |
| 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 | 00:17 |
| dtchen | also, to avoid having to fetch alsa-info.sh each time, mdz added apport hooks to accomplish a subset of the functions | 00:17 |
| 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 | 00:18 |
| dtchen | let's review what we've covered | 00:19 |
| dtchen | first, identify which part(s) of the audio stack are involved. then, open tasks in the bug. | 00:19 |
| bcurtiswx | andresmujica: dtchen: any plans to develop a symptom based apport hook? | 00: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. | 00:20 |
| dtchen | andresmujica: i'd love to see others help there | 00:20 |
| dtchen | any questions regarding basic sound triaging? we'll continue shortly if there aren't any. | 00: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? | 00:22 |
| dtchen | kermiac: there's generally no need to; if there is, someone will ask for it | 00:22 |
| dtchen | (where the someone is generally someone on the kernel team, or me, or upstream) | 00:23 |
| dtchen | ok, so let's discuss symptoms. remember the three major classes: | 00:23 |
| dtchen | 18:27 < dtchen> 0. sound muted bugs | 00:23 |
| dtchen | 18:27 < dtchen> 1. audio anomaly (crackling, popping) bugs | 00:23 |
| dtchen | 18:27 < dtchen> 2. general infrastructure bugs | 00:23 |
| dtchen | (0) is pretty straightforward from a triaging perspective | 00:24 |
| dtchen | look at the Card*.Amixer.values.txt in the bug attachment | 00:25 |
| dtchen | or the relevant section in the alsa-info.txt | 00:25 |
| dtchen | because there's not one common set of mixer elements, you just have to learn which ones are important based on the codec | 00:26 |
| dtchen | BTW, mapping mixer elements to codecs is highly useful; a wiki page could be a prelim DB | 00:26 |
| maco | you mean saying things like how on my laptop the headphones are actually called Surround? | 00:27 |
| dtchen | in general, you want to look at 'Master', 'PCM', 'Wave', 'Front', 'Surround', 'Headphone', 'Speaker' | 00:27 |
| dtchen | note that not all codecs will have all (or any!) of those elements | 00:27 |
| dtchen | in upstream-speak, it's the mixer confusion, and it's one thing that PA is addressing via another mixer abstraction layer | 00:28 |
| 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 | 00:29 |
| dtchen | in that case, ask for them to be unmuted and raised | 00: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" | 00:29 |
| dtchen | now for the fun part: how does one decide whether it's PA or alsa-utils? | 00:30 |
| 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 | 00:31 |
| dtchen | e.g., login on tty, look at alsamixer | 00:33 |
| dtchen | tty1* | 00:33 |
| andresmujica | zyb: But what if the important mixer isn't even displayed, because its "chan1"? or is that in the files anyway? | 00:34 |
| maco | oh | 00:34 |
| maco | (wrong window) | 00:34 |
| dtchen | zyb: please clarify to what chan1 refers | 00:34 |
| zyb | Thats it! One Name meaningless to all but the developer that chose it | 00:36 |
| dtchen | zyb: as of Jaunty, by default alsamixer and amixer expose the ALSA-lib view, not the PA view | 00:36 |
| zyb | and therefore not supported by any program | 00:37 |
| dtchen | in Intrepid, there was some confusion, so one needed to use alsamixer -Dhw:0 | 00: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) | 00:37 |
| dtchen | zyb: then someone needs to stab repeatedly until it's fixed in the source code | 00:37 |
| dtchen | zyb: there's a lot of trial and error in debugging the new codecs | 00:38 |
| dtchen | sometimes even older ones, e.g., the latest alsa-utils upload | 00:38 |
| dtchen | any further questions? | 00:39 |
| bcurtiswx | nothing so far dtchen | 00:40 |
| bcurtiswx | is there a wiki page with all of this valuable information? | 00:40 |
| 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 | 00:41 |
| dtchen | note that other peripherals, like the bus latency of video devices, can affect (1) | 00:41 |
| 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 | 00:43 |
| dtchen | other distributions have done similarly, choosing something between 1 MB and 2 MB inclusive | 00:43 |
| dtchen | rtkit in Karmic will also help if the necessary linux patches are merged (they're being discussed ATM) | 00:44 |
| dtchen | these symptoms are less prevalent in Karmic but fairly evident using PA in Jaunty | 00:44 |
| maco | #define rtkit? | 00:44 |
| dtchen | "apt-cache show rtkit" | 00:45 |
| maco | oh its a package. ok | 00:45 |
| dtchen | any questions on debugging (1)? | 00:45 |
| andresmujica | is this related to that ? pulseaudio[4959]: alsa-sink.c: Increasing minimal latency to 76,00 ms | 00:46 |
| dtchen | andresmujica: yes, it is related | 00:47 |
| dtchen | essentially your hardware requires a higher watermark, so PA adjusts for you and will buffer more | 00:47 |
| dtchen | if it holds steady, it will attempt to decrease | 00: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... | 00:47 |
| dtchen | well, for people who MUST use Skype, use the new Skype with PA support. | 00:48 |
| andresmujica | i mean corporate VoIP ... | 00:48 |
| andresmujica | not skype.. | 00:48 |
| andresmujica | but that's a different story.. | 00:49 |
| dtchen | andresmujica: there are workarounds, like disabling glitch-free and flatvol | 00:49 |
| dtchen | it's really hard to anticipate all sorts of broken hardware combinations | 00:49 |
| andresmujica | so PA shows more clearly the HW problems not detected previously by alsa? | 00:50 |
| maco | yeah | 00:50 |
| dtchen | no, they were always there in ALSA | 00:51 |
| dtchen | i really can't emphasise that enough | 00:51 |
| dtchen | e.g., it's not as if that fpe bug would not have existed if PA hadn't existed :-) | 00:51 |
| maco | dtchen: but whether they were *noticed* or not...? | 00:52 |
| 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 | 00:53 |
| dtchen | these are situations where volume controls are not present in the default distro | 00:53 |
| dtchen | these are mostly Low- or Wishlist-priority bugs | 00:54 |
| dtchen | the obvious usability perspective is important, but people need to step in to help resolve those | 00:54 |
| dtchen | lastly, what's in store for Karmic{,+1} : | 00:55 |
| dtchen | it's important to track the ~ubuntu-audio-dev PPA and continue to file bugs | 00:56 |
| dtchen | for the purpose of PulseAudio, it is legitimate to file bugs UNTIL Karmic's release against the PPA version | 00:56 |
| dtchen | at the point of Karmic's release in October, bugs filed against the PPA version of PA will be Invalidated | 00:57 |
| dtchen | it's important to note that this policy is ONLY valid for PA in Karmic and ONLY while Karmic is open for development | 00:58 |
| dtchen | currently, there are a couple of high priority bugs for PA: session state confusion, i.e., volume being muted on session login | 01:00 |
| dtchen | also, device enumeration | 01:00 |
| dtchen | any questions in conclusion? | 01:00 |
| andresmujica | what about upstreaming PA bugs ? is there a policy for that? when it should be done? | 01:02 |
| dtchen | andresmujica: users tend to do that; distros tend to use pulseaudio-discuss | 01:03 |
| zyb | something about karmic+1? Was mentioned at beginning | 01:04 |
| dtchen | andresmujica: i see nothing wrong with encouraging individual users to do so, but many of our changes were Ubuntu-specific | 01:04 |
| dtchen | zyb: there's a lot on the plate for +1 : native multiarch, power-down configurations, "tracing sound routes" | 01:05 |
| zyb | tracing like traceroute? cool!! | 01:07 |
| dtchen | bcurtiswx: no, but one of the reasons i opted for a lot of background info is to enable wikifying the info | 01:07 |
| dtchen | anyhow, if there are no further questions, i'm happy to head out. thanks, everyone! | 01:08 |
| kermiac | thanks dtchen | 01:08 |
| andresmujica | thanks to you dtchen!! thanks for your time! | 01:08 |
| bcurtiswx | dtchen: cool thx | 01:09 |
| dtchen | i've pasted the irc log in https://wiki.ubuntu.com/Packaging/Training/Logs/2009-08-28 | 01:13 |
| dtchen | if someone wants to clean it up, feel free | 01:14 |
| jawnsy | dtchen: thanks :-) I actually didn't know this session was happening but I'm happy I was here, some interesting stuff discussed :-) | 01:17 |
| Out_Cold | thanks | 01:39 |
| hggdh | er. Where can I find the logs for the classroom? | 02:36 |
| kermiac | https://wiki.ubuntu.com/Packaging/Training/Logs/2009-08-28 | 02:41 |
| nhandler | hggdh: Logs from the packaging training sessions are on https://wiki.ubuntu.com/Packaging/Training/Logs | 02:41 |
| hggdh | nhandler, I was actually looking for the logs from Dan's training | 02:41 |
| hggdh | just got home, and wanted to look at them | 02:42 |
| hggdh | ah | 02:43 |
| hggdh | sorry | 02:43 |
| hggdh | can I (later on) reposition them under the bug knowledge wiki? | 02:44 |
| nhandler | hggdh: Just link to them from the bug knowledge wiki (or use the Include tag). No need to actually move it | 02:45 |
| hggdh | right | 03:06 |
| === arvind_k is now known as arvind_khadri | ||
| === stochastic is now known as stochastic_ | ||
| === Quintasan_ is now known as Quintasan | ||
| jopojop | hello | 13:12 |
| jopojop | testi | 13:14 |
| tim_ | Is there anyway to review the Ubuntu Developer Week sessions if you can't attend the specified timeslot? | 18:15 |
| porthose | tim_, yes the IRC logs should be available | 18:20 |
| nhandler | tim_: Clicking on a session in the table on https://wiki.ubuntu.com/UbuntuDeveloperWeek will take you to the logs once they are posted | 18:21 |
| tim_ | Sounds great - thanks. This may be standard operating procedure, but for newbies like me it might be useful to update the wiki with a note explaining what to do if you can't make the timeslot (my apologies if its there and I missed it) | 18:26 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!