Summary: | System Settings crashed when trying to configure multimedia setting | ||
---|---|---|---|
Product: | [Frameworks and Libraries] Phonon | Reporter: | Frode Tennebø <frode> |
Component: | Xine backend | Assignee: | Matthias Kretz <kretz> |
Status: | RESOLVED DUPLICATE | ||
Severity: | crash | CC: | colin, martin.sandsmark, rdieter |
Priority: | NOR | ||
Version: | 4.3.1 (KDE 4.4) | ||
Target Milestone: | --- | ||
Platform: | Fedora RPMs | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Frode Tennebø
2010-03-17 15:05:49 UTC
Hm, either this is a duplicate of bug 196320 or related to pulseaudio. Colin, any ideas? It could be another case of the now infamous QEventLoop bug in the PA detection code #228324 There are two QEventLoops kicking around (different this= pointers at any rate) in the backtrace, so I'm edging towards that being the cause. Is this still valid if you install the latest phonon packages in RH? Which I believe Rex has pushed. I was using [root@luke ~]# rpm -q phonon phonon-4.3.80-5.fc12.i686 with Build Date: Thu 21 Jan 2010 09:51:28 PM CET Install Date: Mon 01 Feb 2010 12:13:28 AM CET I have done some tinkering and now suddenly I have three output devices, two SB Audigy 2 [SB0204][something] and one PulseAudio. Now, only the PulseAudio options + Test gives the crash effect. The initial report was based on only having one output device (which I believe was PulseAudio). (PulseAudio seems to be a repeating source of problems - it appears to cause crashes in everything from Metacity to Firefox - but is frustratingly figure out.) (In reply to comment #3) > I was using > > [root@luke ~]# rpm -q phonon > phonon-4.3.80-5.fc12.i686 > > with > > Build Date: Thu 21 Jan 2010 09:51:28 PM CET > Install Date: Mon 01 Feb 2010 12:13:28 AM CET This is from before the fixes to the PA detection code in Phonon so it will certainly have some problems. > I have done some tinkering and now suddenly I have three output devices, two SB > Audigy 2 [SB0204][something] and one PulseAudio. Now, only the PulseAudio > options + Test gives the crash effect. The initial report was based on only > having one output device (which I believe was PulseAudio). It means that you are no longer running a PA daemon. Phonon no longer lists the PA option when PA is not running, but your version is a too old for that. Either configure your system to use PA or not, but it's a bad idea to try and mix and match direct alsa and PA together... that path leads to pain! > (PulseAudio seems to be a repeating source of problems - it appears to cause > crashes in everything from Metacity to Firefox - but is frustratingly figure > out.) Well it's quite interesting really. PA development has highlighted a lot of problems with other applications - either in their alsa implementation or their inappropriate use of various third party libraries' APIs that you simply wouldn't expect (e.g. libxml2's xmlCleanupParser() or librsvg's rsvg_term() - yes these methods are dangerous!). In addition PA makes use of parts of the ALSA API that no other ALSA client has used before and that has unearthed several problems in both libasla and in the alsa drivers themselves. Some people want to group these up as "pulseaudio bugs" but in reality these bugs can be far and wide and they are just *exposed* by PA. Some people don't really care about that distinction, but I like to think that PA rollout, while painful for some, has resulted in better code all round in a number of both related and unrelated projects. (In reply to comment #4) > > This is from before the fixes to the PA detection code in Phonon so it will > certainly have some problems. There is no newer version in the stable repository, but in testing. It is safe enough? > It means that you are no longer running a PA daemon. Phonon no longer lists the > PA option when PA is not running, but your version is a too old for that. So why does it crash when trying to use a service which is not running? > Either configure your system to use PA or not, but it's a bad idea to try and > mix and match direct alsa and PA together... that path leads to pain! Sorry, I was trying to disable PulseAudio as I a) wasn't getting any sound and b) had all these strange crashes and 100% CPU usage from various processes, apparently PA related. Somehow it is not very easy to totally disable PA... > Well it's quite interesting really. PA development has highlighted a lot of > problems with other applications - either in their alsa implementation or their > inappropriate use of various third party libraries' APIs that you simply > wouldn't expect (e.g. libxml2's xmlCleanupParser() or librsvg's rsvg_term() - > yes these methods are dangerous!). In addition PA makes use of parts of the > ALSA API that no other ALSA client has used before and that has unearthed > several problems in both libasla and in the alsa drivers themselves. Some > people want to group these up as "pulseaudio bugs" but in reality these bugs > can be far and wide and they are just *exposed* by PA. Some people don't really > care about that distinction, but I like to think that PA rollout, while painful > for some, has resulted in better code all round in a number of both related and > unrelated projects. Sorry for sounding overly critical, and I'm sure that there are other factors involved as well. There are really two fundamental grievances I have which doesn't really reflect on PA directly: * Something broke with FC12 (FC8-11 was fine) regarding PA - or it could be the move to SB Audigy 2 (but it appears to be standard HW...) - but something slipped QA at Fedora Project * The current sound infrastructure/architecture in Linux is overly complex and PA tries to solve that by adding additional abstractions. I'm in the camp which roots for simplicity, not complexity. ;-) (In reply to comment #5) > (In reply to comment #4) > > > > This is from before the fixes to the PA detection code in Phonon so it will > > certainly have some problems. > > There is no newer version in the stable repository, but in testing. It is safe > enough? I don't know Fedora specific stuff I'm afraid. Rex may be able to say, but I guess it will be stable enough otherwise it wouldn't be ready for testing... :p > > It means that you are no longer running a PA daemon. Phonon no longer lists the > > PA option when PA is not running, but your version is a too old for that. > > So why does it crash when trying to use a service which is not running? This is something specific to the backend in question. If it doesn't protect against things nicely, then it will fail. With newer phonon, this will not happen with PulseAudio any more as such interaction is processed before it even reaches the backend specific stuff. > > Either configure your system to use PA or not, but it's a bad idea to try and > > mix and match direct alsa and PA together... that path leads to pain! > > Sorry, I was trying to disable PulseAudio as I a) wasn't getting any sound and > b) had all these strange crashes and 100% CPU usage from various processes, > apparently PA related. > > Somehow it is not very easy to totally disable PA... You should raise this with the Fedora guys. In Mandriva we have a tick box you untick if you don't want PA. Obviously the end goal is to make 99% of users totally unaware of PA or what it is etc. and for that we need to fix cases like this. > Sorry for sounding overly critical, and I'm sure that there are other factors > involved as well. There are really two fundamental grievances I have which > doesn't really reflect on PA directly: > > * Something broke with FC12 (FC8-11 was fine) regarding PA - or it could be the > move to SB Audigy 2 (but it appears to be standard HW...) - but something > slipped QA at Fedora Project Creative h/w is particularly poorly supported under linux sadly. I believe the company doesn't really help very much in this regard (i.e. with specs etc.). The timer based scheduling approach of PA (the newer bit of the ALSA API mentioned in my previous comment that no other ALSA client utilises yet) exposes parts of the driver code that have not yet been tested widely and the creative drivers suffered from a lot of problems in this area as a result. Newer kernels behave better with this h/w AFAIK. > * The current sound infrastructure/architecture in Linux is overly complex and > PA tries to solve that by adding additional abstractions. I'm in the camp > which roots for simplicity, not complexity. ;-) I can see your thinking but I disagree. If you look at the alsa library it's an abstraction of the raw kernel interface to the drivers. This is a very good thing and one of the main design benefits of an ALSA system over an OSS system. Kernel level changes can be abstracted via an updated library that (literally) every alsa client uses. This means that when the kernel interface changes we don't have to update a million applications. This level of abstraction is definitely a good thing, but it's still quite specific. e.g. an application opens a single device. There is a concept of a "default" device which helps but it's still device specific. There needs to be some kind of abstract "output sound" system that can take care of ultimately routing the audio from the application to the chosen device. Whether this system is rolled into the alsa library or done via a separate project like PA only really differs by name. The level of abstraction provided by libasound and PA is really rather small and necessary. The PA core itself is zero-copy and lock-free, providing as transparent a process as is possible for a given situation. The approach taken by libasound+PA is really rather similar to how CoreAudio works on OSX. So not all layers are unnecessary. If you think about phonon itself, it adds another two layers on top of this too :p Anyway this is not the place to have such discussions, so I wont debate or reason any further here on this particular topic. *** This bug has been marked as a duplicate of bug 220071 *** |