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 at 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.
