[pulseaudio-discuss] [RFC] Passthrough support

[Tanu Kaskinen]

On Tue, 2011-02-15 at 22:02 +0530, Arun Raghavan wrote:
> Hey folks,
> I've put up a draft proposed API changes to get passthrough support to
> the point where things Just Work™ for at least the common cases, based
> on previous discussion on-/off-list:
> 
> http://pulseaudio.org/wiki/PassthroughSupport
> 
> Please review/comment. Once we have some consensus, I'll send in patches
> to actually get this done.

Good initiative! My comments:

I'm not sure the query function is needed. If its purpose is just to
enable stream format negotiation, I'd do it so that when connecting the
stream, some representation of the set of formats that the client
supports for the new stream would be provided by the client. The
representation might be a proplist, or something else. It's then up to
the server to select the exact format. The format set representation
might support ordering by preference, so that the client would have more
control. The final format could then be queried from the pa_stream
object. If the representation would be something else than a proplist,
then I guess it would be ok to create a special function for creating a
passthrough stream. The point of this proposal is that this would avoid
two round-trips to the server: first the _get_actual_sink() call and
then the _get_sink_info_by_index() call.

Does the assumption, that all sinks support PCM streams, cause some
actual consequences in terms of API? I can't immediately see any
consequences - it seems like an implementation detail that can be
changed later. (I'd like to reserve the possibility to have
passthrough-only sinks in the future, just in case.)

Pierre had a comment about moving streams between compressed and PCM
sinks. It seems that we understood the proposal differently. Pierre
talks about waiting the client to start sending the correctly formatted
data before finishing the move, but isn't the proposal such that there
doesn't need to be any waiting logic? When moving is initiated, the
stream is actually killed and the client is notified that it should
create another stream.

I vote for disabling monitor sources altogether for passthrough sinks,
at least in the first phase, unless it's trivial to send the compressed
data in some way that is actually useful. Sending silence doesn't sound
useful to me.

-- 
Tanu