[pulseaudio-discuss] [RFC] Passthrough support

[Arun Raghavan]

Hi Tanu,

On Thu, 2011-02-17 at 09:45 +0200, Tanu Kaskinen wrote:
> 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:

Thanks for the detailed proposal!

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

This sounds pretty clean overall, and after talking to Wim on IRC for a
bit, I think we might even be able to do without the no-formats variant
of the API. That said, it would be nice to have the last bit as well, so
I'll keep it put it down as something to add after the basic bits are
done.

I've updated the wiki with this version now.

Cheers,
Arun