[pulseaudio-discuss] [PATCH 4/6] Notify port available status changes
david.henningsson at canonical.com
Thu Nov 10 12:26:20 PST 2011
On 11/10/2011 05:55 PM, Tanu Kaskinen wrote:
> On Wed, 2011-11-09 at 09:51 +0100, David Henningsson wrote:
>> On 11/08/2011 06:52 PM, Tanu Kaskinen wrote:
>>> On Tue, 2011-11-08 at 09:09 +0100, David Henningsson wrote:
>>>> On 11/03/2011 08:22 PM, Tanu Kaskinen wrote:
>>>> > I'd like ports to have their own subscription class.
>>>> I also think that could be nice, and I looked into that, but as I
>>>> understand it, it would require every port to be registered with the
>>>> core (so it gets an index that is used when things change) and several
>>>> API additions to make it useful.
>>> I'm not sure what you mean by "several API additions", but at least
>>> registering port objects to the core would be something that I'd
>>> actually like to see happen.
>> Sure, and I'm not saying doing so would be wrong, but it would require
>> changes to the core, the protocol, the client API, etc. It is not work I
>> can sign up for at this time.
> This is part of the public API. We can't easily change it once we decide
> something. In my opinion having a separate subscription class for ports
> is definitely the right choice, so I oppose pretty strongly promising
> applications that they can catch port status changes with
> card/sink/source events.
Ok, let's leave the notification out for the time being. How do other
people feel about making ports a first class object (registered with the
core, and all that)?
> One option is that we agree to officially not support port status
> notifications at this point, and implement the right solution later. I
> assume you have or will have some client code that relies on this
> notification mechanism. When we eventually introduce the port
> subscription class, your application will stop working. I don't know if
> that would be ok to you or not.
Hrm, this sounds a little ugly. If so, we could just as well distro
patch the notification mechanism.
David Henningsson, Canonical Ltd.
More information about the pulseaudio-discuss