Description of problem: I have constant dropouts when playing music on the fedora 12 beta, manifesting almost as a fluttering sound on top of the music (I guess because each dropout is very short in duration). I have a fair amount of trouble with PA audio on F11 (though F10 was better) and wanted to check what problems rear their head in the beta. This seems to be related to latency settings, as the fluttering disappears when pavucontrol starts (and I see a corresponding change in latency in pulseaudio logs). Playback is perfect if pulseaudio is started with tsched=0. More use of the beta might turn up more problems (I sometimes get a different type of distortion on F11, but I haven't run across this in the F12 Beta yet.) This bug report will be dedicated to this set of symptons. Further details: I tested with both aplay and paplay (rather than e.g. mplayer or totem) as they're hopefully the most well-behaved users of pulseaudio/alsa. Firstly, I checked that 'aplay -D front some.wav' played back perfectly, then I tried 'aplay some.wav' and heard the fluttering. Same with 'paplay some.wav'. Launching pavucontrol during playback immediately fixes the fluttering, although dropouts get much worse if I then close it - they now become noticeably longer and can't be mistaken for fluttering anymore. When paplay starts, I was surpised to see almost no cpu activity even though I get fluttering/dropouts. But when pavucontrol is started pulseaudio takes 6-7%, pavucontrol 2-4% and paplay 1% on a 1.6GHz Athlon xp. Some of this may be due to the volume meter on the active tab and some may be due to pavucontrol itself (pulseaudio takes 3-4% and pavucontrol 2% even when no streams are playing). I didn't compare how much pavucontrol affects cpu usage when testing aplay. Looking into the 'pulseaudio -vvvv' output when paplay starts and when pavucontrol starts and exits, it looks like pavucontrol sets the latency much lower (and it's rest to a higher value when pavucontrol exits), perhaps explaining the difference in cpu usage and dropouts. If so, I guess the question is why pulseaudio chooses a too large initial latency and why it doesn't notice the dropouts and adjust the latency accordingly. (Note that aplay sets the latency to a differenct value than paplay does. I don't want to even speculate what this means) Version-Release number of selected component (if applicable): kernel-2.6.31.1-56.fc12.i686 pulseaudio-0.9.19-1.fc12.i686 alsa-lib-1.0.21-3.fc12.i686
Created attachment 366144 [details] pulseaudio -vvvvv output with paplay Here's the pulseaudio output when I play a .wav file with paplay. Pavucontrol is started during playback and then exited. Pulseaudio is killed after the track ends.
Created attachment 366145 [details] pulseaudio -vvvvv output with aplay Here's the pulseaudio output when I play a .wav file with aplay. Pavucontrol is started during playback and kept open until after the song ends. Pulseaudio is killed after the track ends.
Created attachment 366146 [details] pulseaudio -vvvvv output with paplay and tsched=0 Here's the pulseaudio output when I play a .wav file with paplay, when pulseaudio is started with tsched=0. Pavucontrol is started during playback and then exited. Pulseaudio is killed after the track ends. But see https://bugzilla.redhat.com/show_bug.cgi?id=485293#c7 about error messages in the log with tsched.
Smells like issues with that specific audio driver. Could you by any chance play around with paplay's --latency== and figure out at which latency setting audio starts to break? (And yes, if you run pavucontrol we lower the playback latency, so that we can show a volume meter that is in sync with what you hear)
If tsched=0 fixes the issues then this sounds a lot as if snd_pcm_rewind() is simply broken on this driver.
Why did you file two bugs about this? what's the difference between this and bug 485293?
OK, will merge the two bugs now. *** This bug has been marked as a duplicate of bug 485293 ***