[pulseaudio-discuss] [RFC] Passthrough support

[Tanu Kaskinen]

On Thu, 2011-02-17 at 02:54 +0530, Arun Raghavan wrote:
> On Wed, 2011-02-16 at 10:39 -0600, pl bossart wrote:
> > >> - I am not sure I understand how/when the query would be used. Seems
> > >> to me like a notification with the formats exposed by the sink
> > >> currently selected would be more usable. And if a change in routing
> > >> happens (new accessory, audio policy, etc), the client is informed and
> > >> can reconfigure to PCM if need be.
> > >
> > > In this scheme, how would the client first determine what formats are
> > > available? The notification will also be required - we can either
> > > piggyback in sink, sink-input and card change notifications, or
> > > introduce a new one for a change in available formats (I prefer the
> > > latter).
> > 
> > The problem is that you don't know on what sink you will play until
> > you have actually created the pa_stream. The audio policy and routing
> > rules may kick in and if you query before you connect you would end-up
> > with a broken configuration.
> 
> But the query API includes all the information that we can provide at
> stream creation/connect time, so things would only break if the query
> and connect are done with different parameters, or if the sink changed
> in the period between the two calls. It should be possible for clients
> to gracefully handle this and renegotiate.

Your proposal would probably work well enough in practice, but I still
would like more an approach where you create a stream and after it gets
routed you finalize the stream format. If routing rules change before
the format is decided, the daemon can tear down the stream and inform
the client that it happened because of routing change. The client knows
now that it should retry. In your proposal the client isn't aware that
routing rules have changed, so it doesn't know why the connection fails.
Also, even if connecting succeeds, but with different routing, the
stream format that the client chooses may be suboptimal.

So, my proposal is the following:

Sinks have a list of format descriptions. One format description is a
tuple consisting of the encoding type and some parameters that are
characteristic for that encoding type. Depending on the parameter, a
parameter value can be a single value, a range, a list or the parameter
may be unset, meaning that anything is allowed. There should also be a
special encoding type "any", that means that the client supports
anything (useful for recording applications that just dump the stream to
a file).

When a client creates a new stream, it gives a similar list of formats
as described above for sinks. The list must cover all formats that the
client can support (usually the list contains only one tuple with only
fixed parameters). The daemon routes the stream to some sink, and then
the daemon takes an intersection of the sink formats and the stream
formats.

If the resulting set contains exactly one fixed format, then that is
used for the stream. If the set contains more options than one fixed
format, then the daemon decides the "best" format using some unspecified
algorithm. If the set is empty, then the stream creation fails.

The client can also choose not to specify any formats. In that case the
routing logic can't use the format as input for decisions, but currently
there's no such routing logic anyway. After routing is done, the stream
enters to a new state, PA_STREAM_ROUTED. In this state the client has to
query the set of formats that the sink supports, and decide the final
format. When the client sets the format, the stream changes state to
PA_STREAM_READY.

-- 
Tanu