[pulseaudio-discuss] [RFC] Passthrough support

[Tanu Kaskinen]

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