[pulseaudio-discuss] Jack detection - Client API for UIs
Arun Raghavan
arun.raghavan at collabora.co.uk
Thu Nov 10 22:15:12 PST 2011
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?
> * 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. 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.
> 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?
Regards,
Arun
More information about the pulseaudio-discuss
mailing list