[pulseaudio-discuss] [RFC] Passthrough support

[Arun Raghavan]

On Tue, 2011-02-15 at 22:14 +0200, Tanu Kaskinen wrote:
> 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.
> 
> Good initiative! My comments:

Thanks for the review!

> I'm not sure the query function is needed. If its purpose is just to
> enable stream format negotiation, I'd do it so that when connecting the
> stream, some representation of the set of formats that the client
> supports for the new stream would be provided by the client. The
> representation might be a proplist, or something else. It's then up to
> the server to select the exact format. The format set representation
> might support ordering by preference, so that the client would have more
> control. The final format could then be queried from the pa_stream
> object. If the representation would be something else than a proplist,
> then I guess it would be ok to create a special function for creating a
> passthrough stream. The point of this proposal is that this would avoid
> two round-trips to the server: first the _get_actual_sink() call and
> then the _get_sink_info_by_index() call.

This is doable, and not mutually exclusive with the query API. We could
offer this as a simple API for clients that want to offload the
negotiation to PA if the need is felt - it would require either breaking
API in pa_stream_connect_playback() or adding a variant that takes an
array of pa_format_info structs.

Having a query makes for a more flexible API, though. For example, it
fits more more neatly with the way GStreamer works - you query the
sink's format and then build your pipeline from source to sink
accordingly. Also, it would probably be good to be able to make this
query for UIs.

> Does the assumption, that all sinks support PCM streams, cause some
> actual consequences in terms of API? I can't immediately see any
> consequences - it seems like an implementation detail that can be
> changed later. (I'd like to reserve the possibility to have
> passthrough-only sinks in the future, just in case.)

Fair enough. The only niggling API change would be adding a
PA_FORMAT_PCM_ANY (it would be unwieldy to return one pa_format_info for
each PCM format).

> Pierre had a comment about moving streams between compressed and PCM
> sinks. It seems that we understood the proposal differently. Pierre
> talks about waiting the client to start sending the correctly formatted
> data before finishing the move, but isn't the proposal such that there
> doesn't need to be any waiting logic? When moving is initiated, the
> stream is actually killed and the client is notified that it should
> create another stream.

You're right, and I think this still needs some fleshing out though, as
I mentioned in another mail.

> I vote for disabling monitor sources altogether for passthrough sinks,
> at least in the first phase, unless it's trivial to send the compressed
> data in some way that is actually useful. Sending silence doesn't sound
> useful to me.

The only potential use I see is possibly for debugging, so I'm fine with
disabling it in general.

-- Arun