[pulseaudio-discuss] [RFC] Passthrough support

[Tanu Kaskinen]

On Wed, 2011-02-23 at 01:00 +0530, Arun Raghavan wrote:
> On Tue, 2011-02-22 at 13:27 -0600, pl bossart wrote:
> > ok. Looks good.
> > One last comment on proplists. If we don't define a set of mandatory
> > elements, then it's going to be really hard to use this
> > pa_stream_new_extended() routine. How will the client figure out what
> > exactly it needs to send for each format?
> 
> I was thinking that his would basically develop as convention, though
> the few basic properties (rate, channels) could be documented along with
> the pa_encoding_t structure. We can document additional properties (for
> example bitrate, if some sink ever needs it) as being optional but
> recommended if available.

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.

-- 
Tanu