[pulseaudio-discuss] [RFC] Passthrough support

[Arun Raghavan]

On Wed, 2011-02-16 at 10:10 +0200, Tanu Kaskinen wrote:
[...]
> 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.

At pipeline setup time, we might not actually have all the information
required to set the sample format. With a manual, non-autoplugged
pipeline, we just set the elements to READY (that's the bit where we
create the context and will do the query) starting from sink to source.

TBH, in most cases, I expect the query to be performed with all
parameters except maybe stream flags and props as NULL. All those other
parameters are only there so that the API doesn't need to change for
use-cases that we don't foresee at the moment.

So in theory, this means that if you determine routing with some
information, but make the connection with more parameters, things might
break and you might need to renegotiate (with a limit on how many times
you do this). In practice, this shouldn't bite us until there is some
significant change to the routing logic, by which time I hope all the
pieces for triggering upstream renegotiation from pulsesink will be in
place. :)

> Can you elaborate on what you had in mind regarding UIs?

As for UIs, it would probably be nice to have some sort of (hidden by
default) way to show supported format in a sink. Of course, pactl/pacmd
would expose this data too. Other than informative purposes, it would
also make debugging simpler ("Hey, my BT headset isn't playing MP3s
automatically" .. "Can you check if it's actually supported using these
simple steps?")

> > > 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.

I didn't get the last bit about what you'd add to the proplist. The
separate enum would work well for the format_info struct, but would you
also suggest extending the API to use the encoding type while setting
up/connecting streams?

-- Arun