Bug 471804

http://www.smolts.org/show?uuid=pub_2dabf29b-bd26-4825-b7ed-ac1db85fec24

Of course mine is an AC_97 problematic machine :-)

But situation is really improved

This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

See no attachment

Hmm, are you using the nvidia closed source driver? It severely inteferes with the process scheduling of the Linux kernel causing PA to miss the deadlines more often.

*** Bug 473695 has been marked as a duplicate of this bug. ***

I am using snd-hda-intel, which exhibits the problem with the pulseaudio alsa emulation libraries.  Removing those libraries and using native alsa solves the problem.

(I also have one application for which I am using the alsa oss emulation to a usb audio device -- works like a champ, once I got the levels squared-away.)

And yes, I'm using the proprietary nvidia driver.

Anything I can do to help you with this?  I'll even buy a mobo with intel hda, if it would help...if you'd like that, where shall I drop-ship it?

 -Scott

(In reply to comment #6)
> I am using snd-hda-intel, which exhibits the problem with the pulseaudio alsa
> emulation libraries.  Removing those libraries and using native alsa solves the
> problem.

I just re-installed the pulse libraries...playback is working, I don't hear any
clicks, even when using compiz with the "dodge" focus effect.

Tried moving output from mplayer to another device, mplayer got stuck running nanosleep()'s...

Restarted mplayer, now I can move streams between devices, works okay.

I'll keep using pulseaudio until (heaven forbid) something breaks...hopefully
it will "just work" now. :)

 -Scott

Created attachment 332747 [details]
after .29 kernel...

I updated the system to .29 kernel and system is fully updated.
This attachment is the output of pulseaudio --vv, as I am suffering of small and rare interruptions (now rewinds are only 256 or 328 bytes...) 

I am running with no option in modprobe.conf

alias eth0 ne2k-pci
alias eth1 skge
alias scsi_hostadapter libata
alias scsi_hostadapter1 ata_piix
alias snd-card-0 snd-intel8x0
options snd-card-0 index=0
#options snd-intel8x0 index=0 ac97_clock=48000
#options snd-intel8x0 index=0 ac97_clock=44100
#options snd-intel8x0 index=0 ac97_clock=41194
options snd-intel8x0 index=0
alias snd-card-1 snd-mpu401
options snd-card-1 index=1
options snd-mpu401 index=1

shall I test with ac97_clock=44100 as per the first lines of the attachment??

I have tested with ac97_clock=44100 and sound is almost as it should be.
Any other information that I can supply???

interruptions are still there (not so evident anyway..), even if situation has improved a lot.

I think that there too many bugs around for same problem (especially for hda driver).
But I don't know if and how they can be merged (solution should be easier if bugs are joined..)

and finally adding tsched=0 to load-module module-hal-detect in /etc/pulse/default.pa, let me have sound as it should be!!!
I changed two lines (I have found load-module module-hal detect line twice..)

no other tweak required on my fully updated F11 system.

The bug is not fixed yet. tsched=0 is a workaround, not a fix.

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

Lennart wrote:

> Hmm, are you using the nvidia closed source driver? It severely inteferes with
> the process scheduling of the Linux kernel causing PA to miss the deadlines
> more often. 

Is there any workaround for that? (other than "don't use the nVidia closed source driver, dummy!"); is tsched=0 the best we can do on a system that uses the nVidia driver?