The latency offset type should be signed (int64_t) so we can also add
a negative latency offset.
This also includes changing the type of the sink/source
offsets and updating pacmd so it handles negative numbers.
A latency offset variable was added to the sink/source struct.
Also a function was introduced to update the latency offset of the
sink/source and a new message type was introduced so we can send the latency
offset to the IO thread.
The latency offset is automatically populated with the latency from the
currently active port.
A latency offset variable was added to the port struct and a function to
set the latency offset.
The latency offset does nothing for now, but it will be later added to
the sink/source latency.
I doesn't make sense to require all callers of
pa_device_port_new() to create the hashmap themselves. There
are and there will be no cases where a port without any
profiles would be desired.
While developing the new UI we had to ask ourselves the question of whether
"speakers" should be considered available when headphones are plugged in.
In most cases, they are not available and therefore we should list them
as such.
OTOH, we don't want unplugging the headphones to be considered an act of
wanting to use the speakers (the user might prefer HDMI), and there might
be line-outs that keeps the speakers from unmuting anyway. So, at this point,
I think the most reasonable would be to make the speakers have
PA_PORT_AVAILABLE_NO when headphones are plugged in and
PA_PORT_AVAILABLE_UNKNOWN when they are not. But we might want to revisit
this decision once we have the priority lists up and running.
The same reasoning applies for "Internal Mic", which should become unavailable
when any other mic is plugged in.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
The recommended way of setting available status is to call
pa_device_port_set_available, which will send a subscription event
to the relevant card. It will also fire a hook.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
This forms the base for being able to expose all ports of all
profiles (even inactive ones) to clients.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Since both cards and sinks can hold references to a port, it makes
sense to reference count them. Although no current implementation
actually has sinks with ports but without a card, it felt wrong
to make it harder to make such an implementation in the future.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
