On Fri, 05.06.09 09:01, Tom spot Callaway (tcallawa@xxxxxxxxxx) wrote: > > On 06/05/2009 06:57 AM, Lennart Poettering wrote: > > Usually running "pulseaudio -vvvvv" in a terminal might give you a > > hint what might be going wrong. > > Lennart, > > Maybe this is a stupid question (you know I am constantly full of them), > but is there any way for pulseaudio to detect this "common" condition > where the audio is skipping and inform the user of the possible > workarounds (maybe a DBUS popup or something directly to syslog). I'm > just considering that the average user might not make the leap to > running "pulseaudio -vvvvv" in a terminal to figuring this out. We are already doing this. We verify all timing related data we get from the driver as far as possible. i.e. everything returned by snd_pcm_delay() and snd_pcm_avail() is checked whether it is in specific bounds. If it is not we log that to syslog and clamp it to something which makes more sense to us. But of couse, there's only so much you can catch and even less than you can fix by clamping with that. In fact this turned out to be very useful to track down a couple of timing overflows in the HDA driver that have now been fixed in the F11 kernel. However there are still some issues left. Just search for "snd_pcm_delay"/"snd_pcm_avail"/"snd_pcm_update_avail" in bugzilla. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
