[Bug 570791] pulsesink: Add support for custom downmix matrizes

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=570791
  GStreamer | gst-plugins-good | git

--- Comment #10 from Arun Raghavan <arun at accosted.net> 2014-11-29 03:13:19 UTC ---
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.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.