core-util: Clamp RLIMIT_RTTIME to what RealtimeKit accepts

In the default configuration, PulseAudio's rlimit-rttime is set to
1000000 (100%), which is higher than what RealtimeKit requires from
its clients (200000, 20%).

Make an attempt to still get realtime scheduling by clamping the
current RLIMIT_RTTIME to what RealtimeKit accepts. Warn about doing
this.
alsa-mixer: Disable headphones when playing to speakers

Assume that the headphone port volume is lower than the speaker volume.
When plugging in headphones, if the path is active, while the jack is
being inserted and before it is actually detected as being plugged in,
it will still receive the signal being played (which is at a higher
volume than it will be when plugged in completely). The volume
difference manifests as a volume spike when the headphones are plugged
in, before the final volume is set.

This patch is required to prevent such a volume spike when plugging in
headphones. The problem is not fixed completely, but the spike is
shortened. To be fixed completely, we need to apply the port volume
before unmuting the new path.
alsa-mixer: Add "Line Out" path

If there is a "Line Out" jack present, then add this path. The fallback
analog-output will be a subset of this path and removed.

I only use the "Line Out Jack" or "Line Out Front Jack" for actual jack
detection - without anything connected to the front jack, it makes little
sense to enable the port.
(Another option could perhaps be to use different paths for stereo line out
and surround line outs, but that could be a possible future improvement.)
native: Don't enable prebuffering when draining

BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=64284
doc: Fix building doxygen docs out of tree
alsa: Fix "Scheduling delay of..." message

The tsched_watermark is in bytes, not in usecs. Fix this by introducing
a new variable, and also use that variable in some places for optimisation.

Signed-off-by: David Henningsson <david.henningsson@canonical.com>
iochannel: Avoid unnecessary wakeup after successful write

To save some CPU (in low latency scenarios), don't re-enable the
"writable" event after it has succeeded. It is very likely the next
write will succeed right away too.

This means that we always need to handle EAGAIN/EWOULDBLOCK as a
successful write of 0 bytes, so I also verified that all callers to
pa_iochannel_write handled this correctly.

Signed-off-by: David Henningsson <david.henningsson@canonical.com>
iochannel: Document modified pa_iochannel_write return value