Bug 531066

Summary: wrong latency with cs46xx card causes constant dropouts
Product: [Fedora] Fedora Reporter: Oliver Henshaw <oliver.henshaw>
Component: pulseaudioAssignee: Lennart Poettering <lpoetter>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: lkundrak, lpoetter, ralston, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-10-26 23:45:13 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
pulseaudio -vvvvv output with paplay
none
pulseaudio -vvvvv output with aplay
none
pulseaudio -vvvvv output with paplay and tsched=0 none

Description Oliver Henshaw 2009-10-26 18:51:22 UTC 
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
Comment 1 Oliver Henshaw 2009-10-26 18:56:12 UTC 
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.
Comment 2 Oliver Henshaw 2009-10-26 18:58:21 UTC 
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.
Comment 3 Oliver Henshaw 2009-10-26 19:01:43 UTC 
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.
Comment 4 Lennart Poettering 2009-10-26 19:02:58 UTC 
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)
Comment 5 Lennart Poettering 2009-10-26 19:04:35 UTC 
If tsched=0 fixes the issues then this sounds a lot as if snd_pcm_rewind() is simply broken on this driver.
Comment 6 Lennart Poettering 2009-10-26 19:21:23 UTC 
Why did you file two bugs about this? what's the difference between this and bug 485293?
Comment 7 Lennart Poettering 2009-10-26 23:45:13 UTC 
OK, will merge the two bugs now.

*** This bug has been marked as a duplicate of bug 485293 ***