[pulseaudio-discuss] [RFC] Passthrough support

Tanu Kaskinen tanuk at iki.fi
Wed Feb 16 23:17:37 PST 2011


On Wed, 2011-02-16 at 23:08 +0000, Colin Guthrie wrote:
> 'Twas brillig, and Arun Raghavan at 16/02/11 21:24 did gyre and gimble:
> > 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.
> 
> Just as a "future proofing" comment, what if the routing rules used the
> fact the stream was compressed in it's decision making as to which sink
> to route it to... ?

If such routing policy becomes desirable at some point, I think we can
still, for now, allow clients not to specify their preferred format when
creating streams. If format based policy starts to make bad decisions
(wrong routing or declining connections altogether), then it becomes a
problem for the applications, and they can be fixed at that point. I
don't think we need to make it a problem for the applications yet.

-- 
Tanu




More information about the pulseaudio-discuss mailing list