[pulseaudio-discuss] [RFC] Passthrough support

[Arun Raghavan]

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