pulseaudio causing crashing of applications

Chris Snook csnook at redhat.com
Thu Jan 31 09:47:01 UTC 2008


Andrew Farris wrote:
> Chris Snook wrote:
>> Andrew Farris wrote:
>>> Benjamin Kreuter wrote:
>>>> No, but I have had problems with pulseaudio and arts on the same 
>>>> system.  I wasn't around to hear the discussion about including 
>>>> pulseaudio in F8...why did we go down that road?
>>>
>>> Maybe because pulseaudio is to arts what playstation is to atari?  
>>> Now I'm a big fan of atari, but its old.  Pulseaudio is very cool, 
>>> just not perfect yet.
>>>
>>
>> Perhaps a better analogy would be 3DO to Atari.  Pulseaudio has a 
>> really cool design, but arts actually makes noise come out of my 
>> speakers. After dozens of F8 installs on 5 different machines, I have 
>> completely given up on getting sound to work with KDE.  If I want 
>> sound, I have F7 and my old Mac.  I imagine Ubuntu would work fine as 
>> well.
>>
>> Don't get me wrong, I'm thrilled that the Gnome developers are pushing 
>> ahead with all this neat stuff, but I wish they'd just let KDE be KDE 
>> if they're not even going to bother testing it.  Every Red Hat/Fedora 
>> release since Red Hat 9 has had glaring KDE bugs not found in any 
>> other distribution.
>>
>>     -- Chris
> 
> You don't think that might have to do with the VERY small group of 
> people attempting to keep it working while pushing the envelope with the 
> newest KDE has to offer?  There is no question that gnome gets more 
> attention in Fedora, but more attention for KDE and getting things like 
> pulseaudio to 'just work' would probably be more likely with more people 
> working on it.  What the few do right now is amazing to even keep KDE in 
> the game.  IMO it has everything to do with just not making it work; not 
> with gnome doing their thing...
> 

On the contrary, the Gnome developers are actively breaking 
otherwise-functional KDE code, and have been for years.  In Red Hat 9, 
the bluecurve KDE clock couldn't even stay synched with the system clock 
under load.  That bug made me 50 minutes late for an exam.  In RHEL 3, 
startkde was modified, for reasons unclear to me, in a way that caused 
it to fail to launch KDE when using an afs homedir under a UP kernel, 
though it worked by accident on SMP kernels.  With FC4, I got so fed up 
with the myriad problems that I used the kde-redhat repository, and 
while it was at times a dependency nightmare, the software worked fine, 
because it was much closer to the upstream KDE code than the bastardized 
in-distro version.

I have absolutely no interest in making Pulseaudio work with KDE.  I 
just want sound to work with KDE.  Unlike Pulseaudio, which has never 
once correctly made noise come out of my speakers (though I once got 
buzzing), arts actually does that, when not interfered with.  Unlike the 
Fedora Gnome developers, the upstream KDE developers actually notice 
when stuff in KDE breaks, so the upstream KDE code tends to work pretty 
well until the Fedora Gnome developers start breaking it in the name of 
getting more people to work on it.

SELinux has actually caused me more headaches than Gnomified KDE, but 
the SELinux developers actually respond to bug reports and fix them, 
sometimes within hours.  With SELinux, the process works, and the result 
has been steadily improving quality.  With Gnomified KDE, a Gnome 
developer decides that the correct fix is to make KDE do things the 
Gnome way, and puts the bug at the very end of his todo list, where is 
remains until bugzilla closes the bug a year later after the release 
goes EOL.  The process is inaccessible to volunteer work from KDE users 
who are unfamiliar with Gnome code, which is why so few people are 
working on KDE in Fedora.  The correct solution is to let KDE do things 
the KDE way, and keep Gnome from interfering.  This will allow 
volunteers in the community to actively participate, and the worst-case 
scenario is that we get stuck with raw upstream KDE, which would be far 
better than we have today.

	-- Chris




More information about the fedora-devel-list mailing list