On Sat, 2011-02-19 at 13:28 +0200, Tanu Kaskinen wrote: > 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. Check. > 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. Agreed. > 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: Ah, I /knew/ I was forgetting something when I added 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. Sounds good - I think the NULL-terminated list is preferable. Thanks Tanu, I've updated the page now. Cheers, Arun
