On Wed, 2011-02-16 at 10:39 -0600, pl bossart wrote: > >> - I am not sure I understand how/when the query would be used. Seems > >> to me like a notification with the formats exposed by the sink > >> currently selected would be more usable. And if a change in routing > >> happens (new accessory, audio policy, etc), the client is informed and > >> can reconfigure to PCM if need be. > > > > In this scheme, how would the client first determine what formats are > > available? The notification will also be required - we can either > > piggyback in sink, sink-input and card change notifications, or > > introduce a new one for a change in available formats (I prefer the > > latter). > > The problem is that you don't know on what sink you will play until > you have actually created the pa_stream. The audio policy and routing > rules may kick in and if you query before you connect you would end-up > with a broken configuration. But the query API includes all the information that we can provide at stream creation/connect time, so things would only break if the query and connect are done with different parameters, or if the sink changed in the period between the two calls. It should be possible for clients to gracefully handle this and renegotiate. > One possibly is to connect as PCM, then get a notification from the > sink that it can actually support compressed data and then configure > the stream. This does solve the problem of connecting and finding the routing changed, but I went with the query API since I think it makes more sense to design around the "normal case" (assuming that the sink disappearing between query and connect is going to be uncommon). > Another possibility is to connect but ask the sink to provide its > capabilities in return. We would then have another call to refine the > stream configuration. Since the query basically includes all the parameters from pa_stream_new() and pa_stream_connect_playback(), doesn't this amount to the same thing as the current proposal? > Maybe we should have a short call on this. Yes, ff we're not able to agree on a solution tomorrow, we could do this over phone/IRC. FWIW, I should be around most of the time except between ~2130 and ~0430 UTC. -- Arun
