[pulseaudio-discuss] [RFC] Passthrough support

[Tanu Kaskinen]

On Wed, 2011-02-16 at 10:26 +0530, Arun Raghavan wrote:
> 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.

What if the stream would be created at the time when GStreamer queries
the sink format? The query apparently already contains information about
the preferred format, otherwise your proposal makes it impossible to do
routing decisions based on the sample spec parameter. pulsesink would
respond to the query by checking the parameters of the created pa_stream
object. If the pipeline building is a heavy process, the stream could be
created in corked state.

Can you elaborate on what you had in mind regarding 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).

I think the PA_SAMPLE_* enumeration should be left alone. Let it be a
legacy thing for clients that aren't interested in anything else than
PCM. pa_format_info doesn't need the pa_sample_spec member. The encoding
type can be provided with a new enumeration with PA_ENCODING_PCM,
PA_ENCODING_MP3 etc. Then the proplist, or whatever is chosen for
representing the format set, can contain information saying that
everything is supported.

-- 
Tanu