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
