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.
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.
This makes the test more robust by:
1. Decreasing the '1' threshold during calibration - the RMS value for
the sine wave will be 0.5, so the previous code was making us take
the ALSA mixer past 0dB.
2. Using the difference rather than absolute value for 0->1 transitions,
so that we're somewhat independent noise in our calculations.
This test is intended to measure real latency by playing a sample to a
sink and capturing that over a loopback interface. The loopback can
either be physical (cable running from headphone out to line in) or
virtual (monitor source or module loopback).
Also included in this is calibration code to make sure that volumes are
sufficiently adjusted to be able to detect the played back signal (and
that there aren't false positives due to line noise).
One of the objectives of all this is to later factor out the setup code
to allow us to easily write more loopback tests for various
functionality (volumes, resampling, mixing, etc.).
This pushes all avahi-client code to a threaded mainloop from the PA
mainloop context. We need to do this because avahi-client makes blocking
D-Bus calls, and we don't want to block the mainloop for that long.
The only exception to this now that I don't see a workaround for is
during module unload time. However, this shouldn't be a huge problem
since in most cases, this will only happen at server shutdown time.
The bulk of the change is partitioning the data so that PA core objects
only (well, mostly) get accessed in the PA mainloop and Avahi calls
happen only in the Avahi threaded mainloop.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=58758
for example:
Profiles:
input:analog-stereo: Analog Stereo Input (sinks: 0, sources: 1, priority. 60)
output:analog-stereo: Analog Stereo Output (sinks: 1, sources: 0, priority. 6000)
it should be "priority: xxx", not "priority. xxx"
Signed-off-by: Peter Meerwald <p.meerwald@bct-electronic.com>
Checking the operation state caused a deadlock, because the state
won't change before my_drain_callback() returns, and it doesn't
return before my_drain_stream_func() calls
pa_threaded_mainloop_accept().
With BlueZ 5, if the remote device suspends the audio, the transport
state will change to "idle" and the endpoint is not required to release
the transport, since this could introduce race conditions. Therefore,
ignore the call to pa_bluetooth_transport_release() if the transport is
not acquired any more.
The new D-Bus API doesn't support access rights, which weren't used by
PulseAudio anyway, but it does solve a race condition: now optional
acquires can be implemented by bluetooth-util atomically using the D-Bus
TryAcquire() method.
BlueZ 5 exposes a 'State' property in the media transport interface.
With regard to PA, this replaces the profile-specific interfaces, since
they were being used to know if the audio was streaming or not.
Add the code to parse the properties of the media transport object when
a PropertiesChanged signal is received.
Note that the transport might have an owner other than BlueZ, and thus
the property changes would be emitted from arbitrary senders. For
performance reasons, the installed match considers the interface name
where the property has changed.
It could be possible to install and remove the D-Bus matches dynamically
when a new owner is registered/unregistered, but filtering based on the
interface name seems good enough already.
Install matches for signals ObjectManager.InterfacesAdded and
ObjectManager.InterfacesRemoved, and process the devices that are
registered and unregistered dynamically.
"pactl subscribe" is running continuously, and without flushing its output is
not usable for "process-on-arrival" per-line tasks, such as grepping. This
patch should fix this. For example, now:
pactl subscribe | grep 'server'
should print only server events as they arrive.
Parse the result of ObjectManager.GetManagedObjects(), which includes
all objects registered, their interfaces and the corresponding
properties per interface.
Any code that runs inside the init() callback sees an invalid module
index. Sometimes init() does things that cause hooks to be fired. This
means that any code that uses hooks may see an invalid module index.
Fix this by assigning the module index before init() is called.
There are no known issues in the upstream code base where an invalid
module index would be used, but an out-of-tree module
(module-murphy-ivi) had a problem with this.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=63923
The 'Name' property of the Device interface became optional in BlueZ 5
and may not be present anymore (that happens when testing against the
PTS 4.7.0), so it's better not to expose it to clients so they don't
rely on its existence.
pa_write() knows two types of operation:
calling send() and calling write()
there is a flag (a pointer to an int) passed to pa_write()
which can remember which write type was successful
if the pointer is NULL or the int is 0, send() is tried first,
with a fallback to write() if send() resulted in ENOTSOCK
pa_fdsem_post() calls pa_write() with a NULL pointer;
unfortunately (at least with HAVE_SYS_EVENTFD_H #define'd) send()
always fails here and write() is called -- causing an extra syscall
quite frequently
strace:
send(17, "\1\0\0\0\0\0\0\0", 8, MSG_NOSIGNAL) = -1 ENOTSOCK (Socket operation on non-socket)
write(17, "\1\0\0\0\0\0\0\0", 8) = 8
the patch adds a write_type field to pa_fdsem to the successful
pa_write() type can be remembered and unnecessary send() calls are
avoided
Signed-off-by: Peter Meerwald <p.meerwald@bct-electronic.com>
Pressing Ctrl-C in a terminal while pasuspender is running
causes the sinks and sources to stay suspended after
pasuspender has exited, which is very annoying. This patch
fixes that problem, and also a similar problem with fork()
failures.
The old code accepted any word that started with "y", "Y",
"n", "N", "t", "T", "f" or "F". Fix this by having
a whitelist of full strings instead of checking just the
first letter.
the check for NEON so far only checked if -mfpu=neon is understood by the compiler,
however, this is not enough:
(i) #include <arm_neon.h> should be checked
(ii) -mfpu=neon must be passed before CFLAGS because eventually the per-library CFLAGS
for NEON code in src/Makefile.am are passed to the compiler before the global CFLAGS
in case the build environment passes CFLAGS to configure and we try to set conflicting
CFLAGS option, the former take precedence; CFLAGS cannot be overridden
this does not fix
http://lists.freedesktop.org/archives/pulseaudio-discuss/2012-December/015570.html
but at least makes the build fail in configure (and not while compiling stuff)
and gives better diagnostics
Signed-off-by: Peter Meerwald <p.meerwald@bct-electronic.com>
Port creation is now slightly different. It is now similar to how
other objects are created (e.g. sinks/sources/cards).
This should become more useful in the future when we move more stuff to
the ports.
Functionally nothing has changed.
