Bug 513421 - phonon-backend-gstreamer: The Audio playback device <foo> does not work, falling back to default
phonon-backend-gstreamer: The Audio playback device <foo> does not work, fall...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: qt (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Ngo Than
Fedora Extras Quality Assurance
:
Depends On:
Blocks: phonon-gst-tracker
  Show dependency treegraph
 
Reported: 2009-07-23 11:17 EDT by Rex Dieter
Modified: 2009-11-29 13:29 EST (History)
7 users (show)

See Also:
Fixed In Version: 4.3.1-102.fc10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-08-16 08:57:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
error screenshot (74.18 KB, image/png)
2009-07-23 11:17 EDT, Rex Dieter
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
KDE Software Compilation 201481 None None None Never

  None (edit)
Description Rex Dieter 2009-07-23 11:17:03 EDT
Created attachment 354874 [details]
error screenshot

When using phonon-backend-gstreamer, I see always (a lot?) the error:

The Audio playback device <foo> does not work, falling back to default

here <foo> can be almost anything, tested PulseAudio and Default anyway.
Comment 1 Rex Dieter 2009-07-23 11:45:28 EDT
oh, using qt-4.5.2-2.fc11.x86_64 (F11 + kde-redhat/unstable builds)
Comment 2 Kevin Kofler 2009-07-23 13:35:31 EDT
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.
Comment 3 Rex Dieter 2009-07-23 13:54:53 EDT
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
Comment 4 Kevin Kofler 2009-07-23 15:09:18 EDT
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).
Comment 5 Sven Lankes 2009-07-23 15:22:12 EDT
Same issue here.

pavuctrl shows "ALSA plug-in [dragon]: ALSA Playback"
Comment 6 Rex Dieter 2009-07-23 15:22:58 EDT
ditto here, ALSA plugin [amarok]
Comment 7 Kevin Kofler 2009-07-23 18:36:47 EDT
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).
Comment 8 Rex Dieter 2009-07-28 10:36:58 EDT
than is working on it.
Comment 9 Rex Dieter 2009-08-15 16:51:50 EDT
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
Comment 10 Kevin Kofler 2009-08-15 17:33:01 EDT
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.
Comment 11 Kevin Kofler 2009-08-15 17:47:39 EDT
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.
Comment 12 Ngo Than 2009-08-16 08:57:01 EDT
it's fixed in qt-4_5_2-8_fc12.
Comment 13 Rex Dieter 2009-08-16 13:10:45 EDT
Initial tests here aren't yielding good results.

No matter what I do, output is now going to "Internal", according to pavucontrol
Comment 14 Fedora Update System 2009-10-11 19:49:06 EDT
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
Comment 15 Fedora Update System 2009-10-11 20:02:50 EDT
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
Comment 16 Fedora Update System 2009-10-11 20:03:33 EDT
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
Comment 17 Fedora Update System 2009-11-11 09:55:48 EST
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.
Comment 18 Fedora Update System 2009-11-11 09:58:49 EST
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.
Comment 19 Oliver Henshaw 2009-11-29 13:29:53 EST
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.)

Note You need to log in before you can comment on or make changes to this bug.