Version: 4.3.80 (using KDE 4.3.4) Compiler: GCC 4.4.2 OS: Linux Installed from: Fedora RPMs When the phonon-xine backend is used, phonon apps do not output any sound. This includes the test button in kcm_phonon, too. All the PA devices are listed correctly in kcm_phonon. Using PHONON_XINE_VERBOSITY=2 I've found that phonon-xine opens the null xine output instead of the correct (PA) one. This happens in Phonon::Xine::AudioOutput::createPort when it doesn't receive a valid deviceDesc. And it doesn't, since the constructor of Phonon::Xine::AudioOutput calls setOutputDevice(0) (see below, notice the index 0 in Phonon::ObjectDescriptionData::fromIndex), but device 0 doesn't exist (as can be seen in the attached list). #0 Phonon::PulseSupport::objectDescriptionIndexes (this=0x698e50, type=AudioOutputDeviceType) at /usr/src/debug/phonon-4.3.80/phonon/pulsesupport.cpp:717 #1 0x00007fffed78ba13 in Phonon::Xine::Backend::objectDescriptionIndexes (this=0x6f2ef0, type=AudioOutputDeviceType) at /usr/src/debug/phonon-4.3.80/xine/backend.cpp:216 #2 0x00000031c0a1d5ed in Phonon::ObjectDescriptionData::fromIndex (type=AudioOutputDeviceType, index=0) at /usr/src/debug/phonon-4.3.80/phonon/objectdescription.cpp:131 #3 0x00007fffed77b8b7 in fromIndex (index=<value optimized out>) at /usr/src/debug/phonon-4.3.80/phonon/objectdescription.h:188 #4 Phonon::Xine::AudioOutput::setOutputDevice (index=<value optimized out>) at /usr/src/debug/phonon-4.3.80/xine/audiooutput.cpp:256 #5 0x00007fffed788478 in Phonon::Xine::Backend::createObject (this=<value optimized out>, c=<value optimized out>, parent= 0x621710, args=<value optimized out>) at /usr/src/debug/phonon-4.3.80/xine/backend.cpp:158 #6 0x00000031c0a38c92 in Phonon::Factory::createAudioOutput (parent=0x621710) at /usr/src/debug/phonon-4.3.80/phonon/factory.cpp:324 #7 0x00000031c0a2ed46 in Phonon::AudioOutputPrivate::createBackendObject (this=0x6229f0) at /usr/src/debug/phonon-4.3.80/phonon/audiooutput.cpp:122 #8 0x00000031c0a2d417 in Phonon::AudioOutputPrivate::init (this=0x6229f0, c=<value optimized out>) at /usr/src/debug/phonon-4.3.80/phonon/audiooutput.cpp:107 #9 0x00000031c0a24c80 in Phonon::createPlayer (category=NoCategory, source=...) at /usr/src/debug/phonon-4.3.80/phonon/mediaobject.cpp:556 #10 0x0000000000400c19 in main () (gdb) print s_outputDeviceIndexes $3 = QMap<QString, int> = { ["sink:alsa_output.1.analog-stereo"] = 3, ["sink:alsa_output.usb-0d8c_PnP_Audio_Device-00.analog-stereo"] = 7, ["sink:cmedia"] = 6, ["sink:dt231_amp"] = 2, ["sink:dt231_eq"] = 1, ["sink:prodigy"] = 5 }
Thanks for this. I'll ahve to try and track things down.... it's odd that setOutputDevice is being called on within the Xine namespace.... I thought I was intercepting these before it got to the backend... (i.e. in the phonon code that calls setOutputDevice on the backend, I check for PA being active and prevent the call reaching it).. This is just from memory tho', so I'll probably be getting that wrong... Oh, right, OK, so I call setOutputDevice() in the constructor - yes I need to do that so that the intercepting actually works IIRC.... but if the PA server has had devices come/go and index 0 does not exist, it could indeed break things.... OK, I'll work on a better fix... I think it'll just require splitting the xine initialisation out a bit and calling the relevant bits only. It should be easy to produce a PA server instance that has no index 0: just start PA, go to pavucontrol's configuration tab and pick "Off" profile for your sound card, then change it back. That should trash index 0. OK, I'll test this tonight. For reference here is the commit that added in the setOutputDevice(0) in the xine constructor: http://colin.guthr.ie/git/phonon/commit/?id=0c9e6efc88b2694493fe79faac7b1802c84abe2d Clearly this is an invalid "fix". Feel free to fiddle with this, but if not I'll try and get to it this evening.
I tried changing the settings in pavucontrol/configuration, as suggested, and found that I ended up with no hardware device (the original one greyed out) and a virtual 'dummy Output'. No sound at all now, and so far I haven't found a way to reverse this.
Hi Anne, Yeah if you change the "Profile" to "off" the real hardware device will become greyed out due to it not being there any more. This will cause the sink relating to that device to be unloaded. As this is typically the first sink to be detected when PA starts up it will have index 0... and this is where my bad assumption in the xine layer comes from - that a device 0 will always exist. So when you change the profile to off, sink 0 is unloaded. If no devices are present at all, PA will automatically load a "Dummy Output" null sink (this is mainly to keep applications happy as quite a lot don't like it when there is no real hardware...). If you change the profile back to what it was before, then PA should be able to load the sink again and the greyed out device should become active again (and Dummy Output will become greyed out). If changing the Profile back doesn't work, then this typically means something has jumped in and started using the audio device.... IIRC knotify has a nasty habit of doing just this - hogging alsa directly. You can check via "fuser /dev/snd/*" to see which pids are accessing the sound hardware. Hope this helps.
It certainly helps me understand the process a little. Unfortunately, though, I haven't got sound back. Changing the device back to analogue stereo didn't change the status. Running 'fuser /dev/snd/* ' named kmix as having control, so I killed it and ran the command again - this time with no output. Back into pavucontrol - and nothing has changed. On the configuration page it still says analogue stereo output, but on the Output page it is still using the dummy hardware :-( Since the device changed to dummy without restarting anything, I've assumed that no restart is necessary - and of course I could be wrong there. Any other information I could gather?
Indeed you're correct re the no-restart needed - it should all just work. I should also have said that the "control" nodes in /dev/snd/ don't really count (multiple apps can happily have these open), so in actual fact kmix was OK. To be honest I don't know what is going on here... it's arguably unrelated to this bug tho' - probably some kind of bug in either pavucontrol or PA itself... I'll be fiddling around tonight on this so I'll see if I can reproduce this one. Failing that if you could open a PA bug and assign it to me there (coling) and attach the "pacmd ls" output when this happens that would be good. I'll probably have to ask for other info but I can explain over there :)
A large number of updates came through today (KDE-Fedora 12), including a kernel update, so after running the update I had to reboot. Sound is back. The correct device is active (Internal Audio Analog Stereo). Xine backend still doesn't work, but with the gstreamer backend the Test sound plays. Amarok is silent.
SVN commit 1078226 by cguthrie: xine: Always ensure we create the correct xine port for audio output. When integrating with pulseaudio it was possible that the port was not correctly created. This could happen if phonon was started and the first device detected from PA was a capture device rather than a playback device (which is unlikely) or if the first device detected was a removable audio device which was subsequently removed before playback started. There are possibly other cases where this could happen too. In this case xine would create a null port. This change reverts a previous 'fix' committed in r1051721. I now issue a special case for dealing with PA support in the createPort() method. As a result I no longer need to special case handle the audioDriverFor() method of the backend so this is now removed. CCBUG: 223662 M +12 -4 audiooutput.cpp M +0 -3 backend.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1078226
Works like a charm on my F12 machine now, but I can't test it on the second (Mandriva 2010.0) one until tomorrow evening... Thanks a lot for such an quick fix!
Applied cleanly to the 4.3.50 SRPM in Mandriva 2010.0 and fixed the problem here, too. Thanks for a second time.
Cool. I'll push out an official Mandriva update soon. Got a few other patches I want to roll into it too.