GNOME Bugzilla – Bug 570791
pulsesink: Add support for custom downmix matrizes
Last modified: 2018-11-03 14:39:02 UTC
Playing a AC3 movie in Totem with PulseAudio results in bad mixing, meaning I can't hear the talking over the background noise of the rain. thaytan helped me debug this: PulseAudio takes all 5 channels and then mixes them badly, when the mixing should happen in the gstreamer pipeline.
I'm not sure what we should be doing about this. Obviously, if the actual final, physical, output is 5.1 channels, we want to output them all. So if pulseaudio is saying it can support that, we need to pass them on. We also don't want to say pulseaudio can't accept that many channels if it can... Suggestions or thoughts are very welcome.
I was speaking to thaytan about this earlier today, he asked me to file this bug. One solution is that PA should know how many channels it is outputting to and tell GStreamer. I believe thaytan is going to have a beer with Lennart at FOSDEM and try and sort this out.
Do you have a stereo audio system? I have Lost *.mkv files with AC3 audio and I have no issues. My sound card suport 7.1 audio system, but I using as stereo system.
Does pulseaudio have API to query the 'native' channel configuration now (and notify us of changes)?
One issue here is also, that ac3dec should send events about the downmix matrix twiddle factors downstream, so that audioconvert could use them. That'd be easier that also sending those over to PA. Now the question of could is how to prefer stereo over 5.1 and co. on the caps in pulsesink.
> ac3dec should send events about the downmix matrix twiddle factors downstream That assumes that the decoder provides API to extract this information (or we'd have to extract it from the bitstream ourselves), which is usually not the case.
Well, in my stereo sound system (support 7.1) I realized that all multichannel video files output a low level volume. Appears that it is playing back sound not the front one, or a mixing of all.
*** Bug 590363 has been marked as a duplicate of this bug. ***
Related to bug #608892. This needs fixes in ac3dec and others to include the GstAudioChannelDownmixMeta on the buffers, and also support for that in pulsesink and inside pulseaudio for custom downmix matrizes.
I see three parts to this problem: 1) PulseAudio itself should do a reasonable job on downmixing in the general case (where the media doesn't have very different custom downmix matrix) -- if we're not doing that, that's a PulseAudio bug 2) PulseAudio should support custom downmix matrices -- we need to add support for that in PulseAudio, and have a mechanism within GStreamer to communicated that information down the pipeline if we have it (so it'd work for audioconvert ! alsasink as well, for example) 3) As Stefan points out, we need a way to decide between the decoder and the sink, what the best thing to do is. For the last part, in PulseAudio, we can present the caps in an order that provides the "native" format first followed by the generic things (so yes, we can provide the native format, and report if it changes). In this scenario, the decoder needs to be clever enough to notice the sink's preference for stereo over multichannel output, and apply a downmix. I'm sure someone will point out cases I'm missing here that would break horribly with logic like this. :) One suggestion that came up when we spoke of this at GstConf -- support only the final hardware caps in pulsesink and plug audioconvert if necessary. I don't entirely agree with this solution because I think this decision is better made in PulseAudio (f.ex. it might be that the output supports both stereo and 5.1ch, and we need to trigger a profile switch -- something I'd like to support doing). Maybe it makes sense to have this as a switch on pulsesink (oh no, more configuration!) -- some sort of "strict mode" where we support only the final sink caps and nothing else. This may be useful in some embedded scenarios where you control the entire system and know what configurations may be supported, but I think for the generic case, this approach would be too limiting.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org'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.freedesktop.org/gstreamer/gst-plugins-good/issues/10.