The VLC backend for phonon sets the audio output configuration of phonon depending on the availability of pulseaudio support in phonon: http://privatepaste.com/8f63aadf5e. So if the user compiles and installs phonon and pulseuadio with USE="-pulseaudio", then activates pulseaudio and does a emerge -uDNav world, phonon-vlc will still use pulseaudios ALSA backend (leading to various curious problems) instead of VLCs pulse backend as the phonon-vlc package does not have a pulseaudio useflag. It's probably not a common situation but it happened to me and without looking at the phonon-vlc code, I probably wouldn't have figured out what was going wrong. As a workaround of the issue, I'd suggest to add a "pulseaudio" useflag to phonon-vlc. Reproducible: Always Steps to Reproduce: 1. Compile phonon and phonon-vlc with USE="-pulseaudio" 2. Set USE="pulseaudio" and do a emerge -uDNav world 3. Use pavucontrol to verify that phonon-vlc uses pulseaudios ALSA wrapper Actual Results: phonon-vlc uses the pulse output module Expected Results: phonon-vlc uses the ALSA output module
Does phonon with pulseaudio and phonon-vlc with alsa do anything useful, or must they always both be the same?
(In reply to comment #1) > Does phonon with pulseaudio and phonon-vlc with alsa do anything useful, or > must they always both be the same? That combination does work to a certain extend as pulseaudio has the ALSA input plugin so that the chain simply becomes: source -> phonon -> vlc -> ALSA -> pulseaudio instead of source -> phonon -> vlc -> pulseaudio However, the setup over the ALSA plugin led to curious problems: For example, the tomahawk audio player (which uses phonon) would produce no sound after pausing and un-pausing (not always but most of the time). The audio output could be restored by seeking or advancing to the next track. Unpredictable stuff like that. I am not aware of *any* advantage of running vlc over the ALSA plugin to pulseaudio than to just using it directly, if that is the question.
Thanks. Send a patch upstream for review.
(In reply to comment #3) > Thanks. > > Send a patch upstream for review. Adding a pulseaudio use flag to phonon-vlc? Or is there a nicer way?
> Send a patch upstream for review. Sorry, that should say (I have) "/sent/ a patch upstream" :)
(In reply to comment #5) > > Send a patch upstream for review. > Sorry, that should say (I have) "/sent/ a patch upstream" :) Ah, perfect! Do you have a link to the patch? I'm curious :)
It's only a baby patch. :P https://git.reviewboard.kde.org/r/106326/diff/#index_header With that (or similar applied) the ebuild is an easy fix.
(In reply to comment #7) > It's only a baby patch. :P > https://git.reviewboard.kde.org/r/106326/diff/#index_header > > With that (or similar applied) the ebuild is an easy fix. True, if they go for it. But disabling pulseaudio support in phonon-vlc if a pulseaudio daemon is running can lead to problems (which is why I opened the bug in the first place) and offering an option to a potentially broken installation can easily lead to frustrated users. I understand that you don't want to add a pulseaudio flag to phonon-vlc when -pulseaudio on that package doesn't mean that it's not potentially still using pulseaudio but the nicer fix, imho, would be to simply let phonon-vlc:pulseaudio depend on phonon:pulseaudio and vice versa. That wouldn't even need a change in the phonon-vlc codebase.
(In reply to comment #8) >the nicer fix, imho, would be to simply let > phonon-vlc:pulseaudio depend on phonon:pulseaudio and vice versa. If you think that is the better fix (I do not use pulseaudio so I have no opinion) then we will do that (in that case I would still prefer to have the patch to be sure that the pulseaudio code is not built).
(In reply to comment #9) > (In reply to comment #8) > >the nicer fix, imho, would be to simply let > > phonon-vlc:pulseaudio depend on phonon:pulseaudio and vice versa. > If you think that is the better fix (I do not use pulseaudio so I have no > opinion) [...] I do, because the patch would: a.) ... without the addition of a new use flag, not fix the initial problem and b.) ... with the addition of the pulseaudio use flag to phonon-vlc open us up to a situation (phonon:+pulseaudio, phonon-vlc:-pulseaudio) that seems to be both broken and not supported by upstream as it could never happen with a full, clean build of upstream sources. > [...] then we will do that (in that case I would still prefer to have the > patch to be sure that the pulseaudio code is not built). To be honest, if I were a phonon maintainer I wouldn't want to apply that patch because it opens up an entirely new code path that that's just not sensible: Running a phonon backend that is not using pulseaudio on a phonon setup that expects to be used with pulseaudio. By linking the two pulseaudio flags (from phonon to phonon-vlc) there is no possibility of that happening anyway as long as all packages play nice. The only way the flag could be misleading on phonon-vlc would be if phonon would build pulseaudio support despite USE=-pulseaudio (leading phonon-vlc to do the same). But in that case, the phonon package would also be broken (which necessarily leads to undefined behaviour in any case) and building pulseaudio support into the backends would actually be the most sensible behaviour, imo.
Good news, upstream has accepted some changes for testing that remove the automagic dependency: http://quickgit.kde.org/index.php?p=phonon-vlc.git&a=shortlog&h=refs/heads/pulse-enabled
(In reply to comment #11) > Good news, upstream has accepted some changes for testing that remove the > automagic dependency: > http://quickgit.kde.org/index.php?p=phonon-vlc.git&a=shortlog&h=refs/heads/ > pulse-enabled Ah, if the check was superfluous in the first place then that's even better. Thanks for all your efforts!
Thanks for reporting. This is fixed in cvs. Please sync in some hours to get the changes. + + 11 Nov 2013; Johannes Huber <johu@gentoo.org> +phonon-vlc-0.7.0.ebuild, + phonon-vlc-9999.ebuild: + Version bump wrt bug #490758. Automagic dependency on media-sound/pulseaudio + fixed by upstream, bug #433627. +
