GNOME Bugzilla – Bug 666361
playbin2: regression: visualisations don't work with pulseaudiosink
Last modified: 2012-02-03 16:43:51 UTC
Using totem 3.2.1 (gnome-3-2 branch), visualisations work with the last GStreamer releases, but not with the current pre-releases/git. Only a first frame of the vis shows, but then nothing else.
Disable pulseaudiosink and all works fine again. playsink->audio_pad_raw in gst_play_sink_reconfigure() is FALSE, presumably because the mp3 data is passed to it as mp3 and the decoding is then handled internally in pulseaudiosinkbin.
I think there are at least two issues here: a) it shouldn't even considering passing through mp3 for me. (I don't think I have activated any formats anywhere, but if I had, it would only be AC3+DTS since my receiver doesn't do mp3) b) the issue with visualisations
(In reply to comment #2) > I think there are at least two issues here: > > a) it shouldn't even considering passing through mp3 for me. (I don't think I > have activated any formats anywhere, but if I had, it would only be AC3+DTS > since my receiver doesn't do mp3) You might have a sink with MP3 decode support (like a Bluetooth headset) turn up dynamically, and it's something that we can't know while setting up the pipeline. > b) the issue with visualisations Wondering if the audio_pad_raw bit can be changed to traverse down the sink to the last pad to see what the real caps going through are. Might be an overly-intrusive change, though.
> > a) it shouldn't even considering passing through mp3 for me. (I don't think I > > have activated any formats anywhere, but if I had, it would only be AC3+DTS > > since my receiver doesn't do mp3) > > You might have a sink with MP3 decode support (like a Bluetooth headset) turn > up dynamically, and it's something that we can't know while setting up the > pipeline. My understanding was that I need to enable passthrough-formats explicitly somewhere in pulseaudio for them to be even considered? Is this only the case for other formats and only for SPDIF outputs or am I simply mistaken here? Then, I'm not sure we really need to be able to handle this once the pipeline is set up. It would be cool of course, but it seems more like a cherry-on-top-of-the-cake kind of thing to me, as long as we're trying not to break basic functionality here.
Any news on this?
The following fix has been pushed: 4e2cf39 pulseaudiosink: Lower rank to prevent autoplugging
Created attachment 206692 [details] [review] pulseaudiosink: Lower rank to prevent autoplugging pulseaudiosink breaks visualisations in its current form, so let's prevent it from being autoplugged for the time being. The best we can hope to do in the 0.10 series is query the list of available sinks and their formats, and expose these as the bin's sinkpad caps. While this is not a comprehensive solution, it will make sure that we're only trying to support compressed formats if we're certain that one exists. The long-term fix for this will be in the form of proper upstream renegotiation support in the 0.11/1.0 series.