On Tue, 2011-02-22 at 10:03 -0600, pl bossart wrote: > Hi Arun, > > >> > I've updated this page with the changes discussed so far (and translated > >> > them into the actual API changes that we need). Please take a look and > >> > let me know if this looks acceptable. > > Couple of comments: > - There is a miss on the pa_format_info. the sampling frequency is > required. The IEC format can be used at various sampling frequencies. > Passing just IEC isn't enough to configure the link with the receiver. > The number of channels could be 2 by default, but we may need to > change this as well for formats like TrueHD or DTS Master. I figured it'd be best to leave everything but the format in the proplist and then let the sink pick out the properties it needs/expects. This allows us to keep the structure generic and lets sinks specify what/how much information they need to be able to decide whether a format is supported or not. > - in case no IEC formats are supported by the sink, what is the > returned value? If this is NULL, meaning there is no support, how do > we fall back to plain PCM? I assume that the every sink that supports PCM will have one format with PA_ENCODING_PCM in its list of supported formats. With the extended API, I'd like to treat PCM and compressed formats as being equal as much as possible. > - in case the routing changes, for example if you plug HDMI or BT, how > do we change the connection? The plan is to have clients disconnect and recreate the stream. We could eventually look at a convenience API to do this. -- Arun
