[pulseaudio-discuss] [RFC] Passthrough support

[Arun Raghavan]

On Tue, 2011-02-22 at 22:52 +0200, Tanu Kaskinen wrote:
[...]
> The set of parameters can potentially grow forever - we don't know what
> parameters may become relevant in the future. So, I think we should
> start by documenting the parameters that we know are important today,
> and define the approach for adding new parameters in the future.
> 
> When thinking about handling unknown parameters, there are four cases
> that need to be considered:
> 
> 1) A sink has a parameter that a client doesn't understand.
> 2) A source has a parameter that a client doesn't understand.
> 3) A playback stream has a parameter that a server doesn't understand.
> 4) A record stream has a parameter that a server doesn't understand.
> 
> The cases 2 and 3 should be easy - if the receiver of the data doesn't
> understand a parameter, it means that it doesn't care. The unknown
> parameter can be just ignored by the negotiation logic, and the final
> format should have that parameter removed from the proplist.
> 
> Cases 1 and 4 are more difficult. One possibility would be to fail the
> negotiation in such case. That would require that the sender always
> specifies explicitly all parameters that it knows about, even if it can
> support anything (IIRC I suggested earlier that a missing parameter
> would mean that everything is supported).
> 
> Another possibility would be to try anyway, and the receiver would then
> kill the stream if the actual payload wasn't satisfactory. What should
> the negotiation logic do in this case? If the unknown parameter is a
> fixed value, the parameter should probably be left in the final format
> proplist. What if the unknown parameter is a range or a list? Maybe the
> negotiation logic should in this case leave the parameter untouched in
> the final format proplist.
> 
> I don't know which approach I like more. The first approach (failing)
> would be "cleaner", but the second approach (trying anyway) would work
> in more cases.

I prefer failing if the pa_stream's properties are not a subset of the
properties specified by the sink/source. As Pierre mentions, in the
foreseeable we're going to be dealing with a limited number of
properties (rate, channels, 2-3 codec parameters), so this approach will
work until the requirements change in some fundamental way.

Cheers,
Arun