The outputs are removed from the idxset before output_free() is
called. Trying to remove them again in output_free(), and asserting
that it should succeed caused crashing whenever outputs were freed.
This bug was introduced in commit
061878b5a4.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=65901
We need the mainloop lock to be taken around pa_mainloop_api_once() to
prevent an assert due to the defer event creation and setting of the
destroy callback not being performed atomically.
This needs us to expose a bit of implementation detail, but this seems
to be the cleanest way without an API change.
The specific problem is that pa_mainloop_api_once() needs to first
create a defer event and then set its destroy callback. If the defer
event is completed before the callback is set, an assert will be
trigerred.
Now that we don't *always* get a callback after having written
something, make sure we can continue writing as long as it fully
succeeds.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
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>
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>
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.)
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.
