On Tue, 2011-02-15 at 22:14 +0200, Tanu Kaskinen wrote: > 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: Thanks for the review! > 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. This is doable, and not mutually exclusive with the query API. We could offer this as a simple API for clients that want to offload the negotiation to PA if the need is felt - it would require either breaking API in pa_stream_connect_playback() or adding a variant that takes an array of pa_format_info structs. Having a query makes for a more flexible API, though. For example, it fits more more neatly with the way GStreamer works - you query the sink's format and then build your pipeline from source to sink accordingly. Also, it would probably be good to be able to make this query for UIs. > 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.) Fair enough. The only niggling API change would be adding a PA_FORMAT_PCM_ANY (it would be unwieldy to return one pa_format_info for each PCM format). > 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. You're right, and I think this still needs some fleshing out though, as I mentioned in another mail. > 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. The only potential use I see is possibly for debugging, so I'm fine with disabling it in general. -- Arun
