On 2/27/2011 22:00, Arun Raghavan wrote:
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
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
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.
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
