After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 666361 - playbin2: regression: visualisations don't work with pulseaudiosink
playbin2: regression: visualisations don't work with pulseaudiosink
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal blocker
: 0.10.31
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-12-16 13:24 UTC by Tim-Philipp Müller
Modified: 2012-02-03 16:43 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
pulseaudiosink: Lower rank to prevent autoplugging (1.33 KB, patch)
2012-02-03 16:42 UTC, Arun Raghavan
committed Details | Review

Description Tim-Philipp Müller 2011-12-16 13:24:02 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.
Comment 1 Tim-Philipp Müller 2011-12-18 01:23:58 UTC
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.
Comment 2 Tim-Philipp Müller 2012-01-09 12:47:38 UTC
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
Comment 3 Arun Raghavan 2012-01-20 04:59:57 UTC
(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.
Comment 4 Tim-Philipp Müller 2012-01-20 13:22:47 UTC
> > 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.
Comment 5 Sebastian Dröge (slomo) 2012-02-02 10:39:13 UTC
Any news on this?
Comment 6 Arun Raghavan 2012-02-03 16:42:08 UTC
The following fix has been pushed:
4e2cf39 pulseaudiosink: Lower rank to prevent autoplugging
Comment 7 Arun Raghavan 2012-02-03 16:42:45 UTC
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.