GNOME Bugzilla – Bug 331875
Wish: support AC3 pass-through
Last modified: 2018-05-24 10:26:50 UTC
That bug has been opened on https://launchpad.net/distros/ubuntu/+source/totem/+bug/28177 "When trying to activate the AC3 pass-through option in the Audio properties dialog it doesn't do so. It always uses what was used before. This works in totem-xine. ... > Thanks for your bug. What version of totem/ubuntu do you use? What version was used "before". The bug is not really useful without those informations, I'm marking it as NEEDINFO for now ... still doesn't work using totem 1.3.90 and gstreamer 0.10.3 ... > How do you know if "AC3 pass-through" is used? ... My receiver/amplifier tells me so"
AC3 pass-through isn't supported by the GStreamer backend at the moment as far as I know (hasn't been supported in 0.8 either if I'm not mistaken). I believe what's mostly missing is a way to tell decodebin in GStreamer to treat AC3 as 'raw' stream rather than to decode it.
I am experiencing this problem as well on Ubuntu Dapper with gstreamer-0.10.5. Does this need to be assigned over to the gstreamer product instead of totem?
> Does this need to be assigned over to the gstreamer product instead of totem? In this case doesn't matter which product the bug is assigned to, the GStreamer folks are aware of the issue and there are blueprints for a decodebin/playbin rewrite that supports this, it's just not there yet.
*** Bug 415492 has been marked as a duplicate of this bug. ***
I tried to play with alsaspdifsink, but failed. (Totem says " Internal GStreamer error: pad problem. Please file a bug at http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer." ) How can I do test with alsaspdifsink?
> I tried to play with alsaspdifsink, but failed. > > (Totem says " Internal GStreamer error: pad problem. Please file a bug at > http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer." ) > > How can I do test with alsaspdifsink? You can't yet - this bug is still open for a reason :) Playbin uses decodebin internally, and decodebin autoplugs decoders until it finds a 'raw' format. There is decodebin2 now which can be told to stop autoplugging (via callbacks) at some point, for example if the capabilities match the sink's, but playbin can't do that yet (this will be fixed once we switch to decodebin2 in playbin; probably needs some more design work/thought on both API and implementation)
Still doesn't work using latest GStreamer and totem (from Ubuntu development branch "jaunty"). Only working under totem-xine.
Hmm, with totem-xine killed off this is quite a regression. While I can select the AC3 Passthrough as a speaker config, it does not seem to do anything. Is this related to pulseaudio? If so, totem/gstreamer should fall back to plain alsa.
This in on an up-to-date Fedora 12 install btw (totem-2.28.4-1.fc12).
Dependent on this happening: http://pulseaudio.org/ticket/167
This is being worked on btw, both on the pulseaudio side and the GStreamer side.
With the next versions of gst-plugins-good and PulseAudio, this should Just Work. You will need to: 1. Set your output to S/PDIF or HDMI 2. Mark off what formats your receiver supports in pavucontrol 3. Make sure nothing else has a stream running 4. Play stuff with Totem 5. ??? 6. Profit
(In reply to comment #12) > With the next versions of gst-plugins-good and PulseAudio, this should Just > Work. I discussed this with Colin during the Desktop Summit. Your work on this feature is much appreciated. > You will need to: > > 1. Set your output to S/PDIF or HDMI > 2. Mark off what formats your receiver supports in pavucontrol Could you please file a bug against gnome-control-center/Sound in the GNOME bugzilla with some details as to what is needed for GNOME to have this ability itself? > 3. Make sure nothing else has a stream running > 4. Play stuff with Totem How would Totem determine that the volume could not be changed? Should I remove the "pass-thru" sound configuration that exists within Totem? (and that I think doesn't do anything nowadays). > 5. ??? > 6. Profit
I'll jot down the stuff that I think we need to look at while dealing with the passthrough stuff in a bug against g-c-c. Currently, we just ignore volume changes in passthrough mode, but clearly we need a proper way to deal with this so players can grey out the control. While it's not that hard to do if you hook into the PA API, a more gst-friendly way could be to have a boolean passthrough property on pulsesink. I'll hack that up if it sounds okay. With this, I don't see any reason to have the separate passthrough mode in Totem's config.
(In reply to comment #14) > I'll jot down the stuff that I think we need to look at while dealing with the > passthrough stuff in a bug against g-c-c. Posted on bug https://bugzilla.gnome.org/show_bug.cgi?id=656674
*** Bug 696040 has been marked as a duplicate of this bug. ***
Trying to gather what's needed to fix this: 1. From comment #1, it would make sense to have an "audio-filter" property on playbin or playsink that can be plugged in on a best-effort basis 2. Might be nice to also signal in UI that volume control will not work. Not sure how this should be communicated from the GStreamer side. Extension to the GstStreamVolume interface perhaps? 3. Patch for signaling rate-control unavailability in comment #2 4. Maybe not for the first iteration, but playbin or decodebin should support reconfiguration when the device format list changes (unplug from HDMI receiver, for example) 5. UI in GNOME for setting formats supported by the receiver? Tracked in bug #656674 Am I missing anything?
(In reply to comment #17) > 1. From comment #1, it would make sense to have an "audio-filter" property on > playbin or playsink that can be plugged in on a best-effort basis This one is already being tracked in bug #679031.
*** Bug 730449 has been marked as a duplicate of this bug. ***
Bug 679031 and bug 728020 were fixed, which means that AC-3 pass-through should now work, though the UI is lagging behind. Testing would be appreciated.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/totem/issues/3.