On Fri, 2011-02-18 at 15:11 +0530, Arun Raghavan wrote: > Hello! > > On Tue, 2011-02-15 at 22:02 +0530, Arun Raghavan wrote: > > Hey folks, > > I've put up a draft proposed API changes to get passthrough support to > > the point where things Just Work? for at least the common cases, based > > on previous discussion on-/off-list: > > > > http://pulseaudio.org/wiki/PassthroughSupport > > > > Please review/comment. Once we have some consensus, I'll send in patches > > to actually get this done. > > 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. I think pa_encoding_t should include PA_ENCODING_ANY for the case where a recording application doesn't care at all about the format. Maybe it would be better to leave out also the channel map from pa_stream_new_extended()? The channel map is relevant only for PCM streams, so putting it in the format info proplist would make sense in my opinion. I believe there's no need to alter the pa_stream_connect_* functions in any way. Returning the final format is not possible at the time when the function returns - the API is asynchronous, so the function only sends a request to the server, it doesn't get any response back. When the response eventually comes from the server, the stream state changes to PA_STREAM_READY, which triggers a callback in the client code. That callback can then query the final format. A new function is needed for that: const pa_format_info * const *pa_stream_get_format_info(pa_stream *s) My proposal is that the return value is a NULL-terminated list, for supporting sink format querying in the future. For now the list will always contain only one item. Another possibility would be returning just a single format info instance here, and defining a separate function for getting the format list in sink format query cases. -- Tanu