[pulseaudio-discuss] [RFC] Passthrough support

[Colin Guthrie]

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


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

Hmm, that could work... not really though through the implications of
adding a new state here, but I don't think it would cause major
headaches downstream.

Col



-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]