On 11/11/2011 03:08 PM, David Henningsson wrote:
On 11/11/2011 12:17 AM, David Henningsson wrote:
Do you think we can merge these different views and come up with an
agreed client API within a couple of days?
Ok, so I can happily say that we had a great IRC conversation on the
topic today. The outcome was:
* Not to register port objects with the core (for the time being)
* Not to add "inactive" sinks/sources to the client API (for the time
being)
* When port availability changes, fire a subscription event for the card.
* I'm not sure we got consensus on if/when the sink/source should also
get a subscription event, but that can be discussed later.
* To change the existing proposal's "is_input" and "is_output" to a
bitfield. Thus the new client API proposal is now attached. I'll start
working on implementing this next week unless I hear massive complaints.
One detail though: should the enums be declared as is (e g
"pa_direction_t direction;") or as ints ("int direction;")? I remember
someone saying enums were more likely to change size than ints.
In line with the client API proposal, here's the matching protocol proposal.
Any objections?
## v25, implemented by >= 2.0
When port availability changes, send a subscription event for the
owning card.
## v26, implemented by >= 2.0
In reply from PA_COMMAND_GET_CARD_INFO (and thus
PA_COMMAND_GET_CARD_INFO_LIST), the following is added:
uint32_t n_ports
...followed by n_ports extended port entries, which look like this:
string name
string description
uint32_t priority
uint32_t available
uint8_t direction
uint32_t n_profiles
string profile_name_1
...
string profile_name_n
Profile names must match earlier sent profile names for the same card.
--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
