On Tue, Feb 22, 2011 at 2:52 PM, Tanu Kaskinen <tanuk at iki.fi> wrote: > 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. I suggest we first work with known mandatory parameters such as sampling freq and nb of channels. The connection fails if these parameters are not set. That's enough to make passthrough work for now. Future extensions can be worked out later. let's not fall into academic debates. -Pierre
