[pulseaudio-discuss] [RFC] Passthrough support

[Arun Raghavan]

On Thu, 2011-02-17 at 09:13 +0000, Colin Guthrie wrote:
> 'Twas brillig, and Tanu Kaskinen at 17/02/11 07:45 did gyre and gimble:
> > 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.
> 
> Yeah, I agree with this statement. It just feels cleaner (my comment
> about the format being used in the routing would still be an issue here
> but I agree that it was probably an extreme example that wouldn't really
> be needed in practice anyway).
> 
> > 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.
> 
> When this fails, should we go back to the routing system and ask to be
> routed again, but not to this failing sink? I can see this being a)
> useful, but b) complicated (not so much complicated on initial
> connection but complicated when a stream may get "re-routed" (i.e. when
> a new, totally unrelated sink comes along, the routing system may
> re-evaluate it's priority lists and try to move the stream to a higher
> priority sink (i.e. the one that failed the first time).

I probably didn't understand this correctly, but wouldn't this only be
helpful if a new sink comes in exactly between when the routing fails
and when you retry?

-- Arun