[pulseaudio-discuss] [RFC] Passthrough support

[Arun Raghavan]

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.

> One possibly is to connect as PCM, then get a notification from the
> sink that it can actually support compressed data and then configure
> the stream.

This does solve the problem of connecting and finding the routing
changed, but I went with the query API since I think it makes more sense
to design around the "normal case" (assuming that the sink disappearing
between query and connect is going to be uncommon).

> Another possibility is to connect but ask the sink to provide its
> capabilities in return. We would then have another call to refine the
> stream configuration.

Since the query basically includes all the parameters from
pa_stream_new() and pa_stream_connect_playback(), doesn't this amount to
the same thing as the current proposal?

> Maybe we should have a short call on this.

Yes, ff we're not able to agree on a solution tomorrow, we could do this
over phone/IRC. FWIW, I should be around most of the time except between
~2130 and ~0430 UTC.

-- Arun