[pulseaudio-discuss] Jack detection - Client API for UIs

[Arun Raghavan]

On Fri, 2011-11-11 at 08:47 +0100, David Henningsson wrote:
> On 11/11/2011 07:15 AM, Arun Raghavan wrote:
> > On Fri, 2011-11-11 at 00:17 +0100, David Henningsson wrote:
> >> Hi PulseAudio developers,
> >>
> >> Upstreaming of the jack detection patches seems to take much longer than
> >> I anticipated. :-( This puts me in a difficult position, as I want to
> >> get started with the UI work of the Gnome sound settings as soon as
> >> possible.
> >>
> >> This is because I want the UI work to go into Ubuntu 12.04, early on, to
> >> get as much testing as possible before release.
> >>
> >> Therefore, Conor and I have planned to do this work in the november time
> >> frame. To get started with that, we need extensions to the client API -
> >> and that within the next couple of days. Shortly thereafter, protocol
> >> extensions matching this client API will need to be agreed on.
> >>
> >> At this point, the status of the client API extension (and apologies if
> >> my perception of your opinions are wrong) is:
> >>
> >>    * I posted a proposal in October [1] but no responses to that message
> >> so far
> >>
> >>    * Arun wants to see inactive sinks being implemented but probably not
> >> exposed through the client API
> > [...]
> >>    * Colin probably wants to see inactive sinks being exposed through the
> >> client API, but is generally open to other suggestions as well
> >
> > I was hoping to get started and do a quick proof-of-concept of my idea
> > this weekend to evaluate whether this is feasible in the short-term or
> > not. Real life is preempting this, so I won't be blocking your patches
> > waiting for this to be solved, and I believe Colin's suggestion was also
> > meant to be a general statement and not a "let's do this instead" thing.
> >
> >>    * Tanu wants to see ports being implemented as "first class objects"
> >> so that notifications can be made on port level. In the long term, Tanu
> >> wants to merge the "port" and "sink"/"source" concepts into one, but at
> >> this point this is just a vague idea.
> >
> > The two issues here are orthogonal (and I believe Tanu was clear about
> > the second part /not/ being part of the near term solution). Is it
> > really so hard to do the notifications right up-front?
> 
> That's a good question. I don't think it's that hard to implement 
> really, once we have a sketch/client API ready. I can commit to making 
> an implementation of ports as core registered objects, if it comes down 
> to that. However, having just seen how much work it is to upstream stuff 
> to PA, I'm not sure I can commit to make all the finishing touches to 
> make upstream happy, so you might have to meet me half-way on that patch 
> (set). Would that be ok?

Yes, I'd be happy to help once we've agreed on an approach.

> >>    * And I...well, I think the proposal in [1] is the quickest way from A
> >> to B, and I'm tempted to take that because I'm in a hurry, but I do
> >> realise that there are long-term considerations as well, very much
> >> depending on which one(s) of the above opinions that will prevail.
> >>
> >> Do you think we can merge these different views and come up with an
> >> agreed client API within a couple of days? The "let's discuss and
> >> discuss again and then we stall a bit and then more discussions and then
> >> see if we ever come to a consensus and if we don't just do nothing"
> >> approach [2] will just not work out for me here. And I really really not
> >> want to make Ubuntu go its own way here with incompatible client API and
> >> protocol extensions either, so please give me a better option :-)
> >
> > I am against trying to set a deadline of the "let's decide in the next 2
> > days" kind.
> 
> We're from different schools. Somewhat over-generalising, you more often 
> prefer the "when ready" approach, where I often prefer the "fixed date" 
> one. There are advantages and disadvantages with both, but we can debate 
> that at another point in time.

We do need to strike a balance, and that's subjective. But your'e right,
a discussion for another day. :)

> > That said, the pending disagreements don't seem to be as
> > gloomy as you think, so we should be able to move forwards on this
> > quickly enough.
> 
> Let's hope you're right.
> 
> >> PS: Will send out new jack detection patches shortly. Only thing changed
> >> is adjustment according to the comments where I believe there was no
> >> dispute.
> >
> > I'll take a fresh look. Am I right in that the pending items are:
> >
> > 1. Notifications on ports as separate objects
> >
> > 2. Tanu's review of patch #6
> >
> > 3. Figuring out where ports fit in the client-visible structures?
> 
> Thanks very much for making this your priority. Yes, I think the summary 
> is good, and I see "1." as being a part of the larger "3.".

Right. I'm worried about 3. actually going back to my concerns with the
internal representation as well. Since we've decided not to block on
that, let's try to come up with something more pragmatic on that front.
I'll take a fresh look at the options here in a bit.

Or perhaps we can do a quick IRC discussion when everyone's around to
get some consensus on the client-side stuff today (if people are free,
else we can continue to pa_asyncmsgq_post() here ;)).

-- Arun