[pulseaudio-discuss] [RFC] Passthrough support

Christ Schlacta lists at aarcane.org
Mon Feb 28 16:48:06 PST 2011

On 2/27/2011 23:29, Arun Raghavan wrote:
> On Sun, 2011-02-27 at 23:20 -0800, Christ Schlacta wrote:
> [...]
>> mark settings as optional or required for negotiation.  if one or the
>> other can't support an "Optional" parameter, then it gets replied to as
>> unsupported but continuing.  a warning is logged.  a mandatory option
>> will cause it to fail with an error message logged (Warning, Remote sink
>> doesn't support required option "bitrate".  either upgrade Remote Sink,
>> or set bitrate as optional by using "optional bitrate foo") or similar.
> We can do this, but what does it really get us? On the sink side, we
> know what restrictions we want to place on the input, and it's
> reasonable to assume anything unspecified is fine (if it's not, it
> should be specified as a restriction anyway).
> On the stream side, we're not providing the information as a restriction
> - we're saying "I have this stream, it can be with one of these
> formats/properties, find me a sink to plug into". What would an optional
> parameter achieve here?
> -- Arun
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
the optional parameter says "If you don't have this, it's fine", whereas 
the mandatory parameter says "If you don't have this, then fail".  It 
allows older and newer software to interoperate, if one end of the 
connection doesn't know about a parameter, it only matters if it's 
mandatory.  the point of the thread was how to allow future changes of 
parameters without breaking compatibility..  that would achieve that 
goal, while allowing the two ends to negotiate when to succeed and when 
to fail, vs. just always trying or always failing.

More information about the pulseaudio-discuss mailing list