oh, using qt-4.5.2-2.fc11.x86_64 (F11 + kde-redhat/unstable builds)

What sink does it end up using? Can you try running pavucontrol and see if it reports "ALSA plugin"? It should not report that, GStreamer should be using the native pulsesink. If you see "ALSA plugin", it's using the alsasink.

What I suspect is that Phonon's device listing is including devices which can't be accessed through the pulsesink.

pavucontrol reports "Internal Audio" as Output Device.

Fwiw, systemsettings reports the following available Output devices:
listing : mouseover caption
-------------------
default : Default audio device
Default : This will try the following devices and use the first: 1. ALSA: default
PulseAudio Sound Server : This will try ... : 1. ALSA: pulse
HDA Intel (...) : This will try ... : 1. ALSA: x-phonon: CARD=0 , 2.  ALSA: plughw: CARD=0

Uh, what I really meant was what's listed on the Playback tab, in the list of applications. That's where it says e.g. "amarok" if it's native, "ALSA plug-in [amarok]" if it's going through the ALSA plugin (which is bad, that's what GStreamer has a pulsesink for).

Same issue here.

pavuctrl shows "ALSA plug-in [dragon]: ALSA Playback"

ditto here, ALSA plugin [amarok]

I think we'll have to patch Phonon-GStreamer to work sanely with PulseAudio just as I had to patch Phonon-Xine.

The minimal fix I can see (which will of course not touch Phonon-GStreamer's 2-step selection hack of "sinks" and "devices", as changing that would be very invasive) is to:
1. make sure the pulsesink is used by default if PulseAudio is present and
2. probably tell the Phonon KDE platform plugin (which returns devices detected by Solid) to STFU if Phonon-GStreamer and the pulsesink are detected (unless Phonon-GStreamer somehow knows what to do with those devices in the presence of the pulsesink; I doubt it does). Maybe we should even just disable the KDE platform plugin entirely with Phonon-GStreamer (it was developed with and for Phonon-Xine).

than is working on it.

Looks like Mandriva has done some similar work, that we could leverage,

http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/phonon/current/SOURCES/phonon-4.3-mandriva-pulseaudio.patch

Looks like that work can be used to base our patch on. However:
* We don't have something like /etc/sysconfig/pulseaudio. We'll need to detect whether PulseAudio should be used in a different way (check if it's running in some way).
* The references to draksound need to go away.
* The phonon-xine part of the patch should be omitted: it just hides all devices except PulseAudio if PA is enabled in Mandriva's /etc/sysconfig/pulseaudio (which we don't have). My patches which just reorder the priorities of the devices so PA comes first when available work better for phonon-xine. Only the first xine/backend.cpp hunk which makes it actually use the iconName property makes sense. We should keep my patches for phonon-xine and add a variant of the Mandriva one for phonon-gstreamer.

My suggestion is to have a function:
bool detectPulseAudio(void);
which:
* dlopens or links to libpulse.so.0,
* tries to open a connection,
* if it succeeds, closes the connection and returns true,
* if it fails, returns false.

Then we can change:
+        // Detect Pulse according to Mandriva config system so we can apply some cosmetic hacks
+        if (m_audioSink == "auto") {
+            QSettings pulseconf("/etc/sysconfig/pulseaudio", QSettings::NativeFormat);
+            if (pulseconf.value( "PULSE_SERVER_TYPE", "None" ) == "personal") {
+                m_audioSink = "pulsesink";
+            }
+        }

to:
+        // Detect PulseAudio so we can apply some cosmetic hacks
+        if (m_audioSink == "auto") {
+            if (detectPulseAudio()) {
+                m_audioSink = "pulsesink";
+            }
+        }


Removing the draksound reference is trivial, just s/Use draksound to configure your PulseAudio preferences and pavucontrol to/Use pavucontrol to/g. Omitting the xine section is also trivial, just delete it from the patch. So all that's really left to do is to write the detectPulseAudio function.

it's fixed in qt-4_5_2-8_fc12.

Initial tests here aren't yielding good results.

No matter what I do, output is now going to "Internal", according to pavucontrol

qt-4.5.3-4.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/qt-4.5.3-4.fc11

phonon-4.3.1-102.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/phonon-4.3.1-102.fc11

phonon-4.3.1-102.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/phonon-4.3.1-102.fc10

phonon-4.3.1-102.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

phonon-4.3.1-102.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

I have the F12 kde livecd, but the phonon device for the internal sound card is at the top for both the gstreamer and xine backends.

"PulseAudio Sound Server" (alsa:pulse) and "Default" (alsa:default) are next in the preference list for both backends. Note that the alsa default device actually is "pulse", the PA alsa plugin.

Neither of the pulseaudio plugins for xine (xine-lib-pulseaudio) and gstreamer (gstreamer-plugins-good) are installed on the livecd. If I do install them, and remove the phonon config files in .config/kde.org/ and .kde/share/config/ then the pulse plugin (i.e. not alsa:pulse) becomes the preferred device for whichever phonon backend was in use.

(If I don't remove the config files or if I switch backends in the gui then the device preference list becomes increasingly busted. But I think you know that already. I don't know what controls the current phonon backend, but it seems to persist through config file removal.)