CXX libwebrtc_util_la-webrtc.lo
modules/echo-cancel/webrtc.cc: In function 'pa_bool_t pa_webrtc_ec_init(pa_core*, pa_echo_canceller*, pa_sample_spec*, pa_channel_map*, pa_sample_spec*, pa_channel_map*, uint32_t*, const char*)':
modules/echo-cancel/webrtc.cc:196:9: warning: 'rm' may be used uninitialized in this function [-Wuninitialized]
Signed-off-by: Peter Meerwald <p.meerwald@bct-electronic.com>
CC libpulsecore_2.98_la-svolume_arm.lo
pulsecore/svolume_arm.c: In function 'pa_volume_s16ne_arm':
pulsecore/svolume_arm.c:50:8: warning: assignment discards 'const' qualifier from pointer target type [enabled by default]
Signed-off-by: Peter Meerwald <p.meerwald@bct-electronic.com>
On Windows, strerror can actually return "Unknown Error"
(e.g. for large errnums). The code assumes the return value to be helpful.
Make it slightly more helpful by catching the message and appending the
errnum.
Calling pa_read() and pa_write() seems more appropriate since they deal better
with platform specific issues. This doesn't actually fix any open issue since
only stdio is affected but it seems more future proof.
On Windows, fdsem.c:flush() fails because sockets are set to non-blocking
mode, since pa_read() returns -1 (and errno == EWOULDBLOCK). I guess pa_read()
is expected to block in this case so make it actually block by calling poll().
Without this reading from stdin will eventually end with EOF (if there happens
to be a newline sign in the stream), because read() returns 0.
This patch fixes raw data input and piping to pacat on Windows.
Instead of repeatedly asking the discovery API to find a device given
our device path, let's hold a pointer to the device and make sure we
remove the reference when the hook is fired reporting that the device
has been removed. This makes the code easier to follow and slightly
more efficient.
The internal API in bluetooth-util should not use the const qualifier
for operations involving a device object. After all, the structure
contains many pointers and thus the const qualifier provides no real
protection.
Sometimes the kernel does not schedule us in due time, thus causing
an underrun. Adding a detection and a debug message will be a helpful
step in determining the cause of an underrun.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
CC pulseaudio-dumpmodules.o
daemon/dumpmodules.c:93:27: warning: redundant redeclaration of ‘lt__PROGRAM__LTX_preloaded_symbols’ [-Wredundant-decls]
/usr/include/ltdl.h:106:36: note: previous declaration of ‘lt__PROGRAM__LTX_preloaded_symbols’ was here
the declaration is provided by ltld.h of libtool since version 2.4, require the 2.4 instead of 2.2
Signed-off-by: Peter Meerwald <p.meerwald@bct-electronic.com>
Instead of repeatedly asking the discovery API to find a transport given
our transport path, let's hold a pointer to the transport and make sure
we remove the reference when the hook is fired reporting that the
transport has been removed. This makes the code easier to follow and
slightly more efficient.
The recently added hook can be used to detect that the transport being
used has been removed. In this case, the profile needs to be set to off.
Additionally, the change fixes a significant problem: without this
transition, the transport could be destroyed while the hook slots (i.e.
nrec_changed_slot) were still set. This led to a double free of these
objects in stop_thread().
The internal API in bluetooth-util should not use the const qualifier
for operations modifying the transport object. This is specially useful
in order to use the available hooks.
If profile could not be successfully initialized, the card should be
set to PROFILE_OFF automatically. If sinks or sources exist, they need
to be destroyed, therefore stop_thread() is called.
Remove stream moving policies from module-bluetooth-device. It is not
clear if such policies are needed at all and in case yes, they should be
implemented in module-bluetooth-policy.
These days we don't set core->default_sink/source as soon as somebody
asks for it. To retain consistent behaviour (i e the asterisk),
we need to call pa_namereg_get_default_sink/source.
Reported-by: Daniel Manrique <daniel.manrique@canonical.com>
Reported-by: Brendan Donegan <brendan.donegan@canonical.com>
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
If the card is being set to off profile, it is not necessary to check
if the device exists. This could potentially happen during shutdown,
immediately before the module is unloaded.
It might happen that a PropertyChanged signal is received but the
corresponding card profile has not been created, leading to an assertion
failure in filter_cb() due to inexistent ports. This can happen if BlueZ
misbehaves, or also if the UUIDs are reported later on (i.e. during
pairing discovery). In any case, the signal should just be ignored.
Handling the signal DisconnectRequested should be unnecessary since the
profile-specific interfaces will be later disconnected, leading to
module unload.
Additionally, the signal is problematic: if an interface (i.e.
A2DP AudioSource) is playing at the time DisconnectRequested is
signaled, the following sequence can occur:
1. AudioSource is playing
2. DisconnectRequested is received
3. Module is unloaded due to DisconnectRequested
4. AudioSource state changes from playing to connected
5. module-bluetooth-discover loads the module
6. AudioSource state changes from connected to disconnected
Therefore the module is unnecessarily loaded, to be unloaded immediately
afterwards. This can easily be reproduced if a device is unpaired while
the audio is streaming.
The simplest solution to this consists of removing step 3, by just
ignoring the DisconnectRequested signal. This reverts commit
8169a6a6c9.
Upstreamed from Debian: "Although in principle Ac '97 hardware has a
separate mono LFE pin nothing seems to use it. To make matters worse
it does confuse PulseAudio's port selection slightly which causes
audio in virtualbox not to work out of the box."
Credit: Sjoerd Simons <sjoerd@debian.org>
Credit: Martin-Éric Racine <martin-eric.racine@iki.fi>
BugLink: https://bugs.launchpad.net/bugs/1016969
BugLink: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673847
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
I was hoping this would improve bootup speed, but it doesn't seem
to do so here, at least not much. But at least it reduces the logs
a little.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
The GNOME-OSTree build system currently creates chroots and bind
mounts to the source tree outside the root; this means that we can't
necessarily run git inside the root, because in the case of git
submodules, the .git repository will point to outside root.
Also, error out fatally if we fail to determine the version; it
makes no sense to put UNKNOWN in e.g. the pkg-config files
since this will just cause errors later on.
Handle availability changes in Bluetooth ports inside
module-bluetooth-policy. The implemented behavior is similar to how
module-switch-on-port-available behaves, but the conditions are more
relaxed and thus more profile changes are triggered.
When PA is doing gateway role, let module-suspend-on-idle resume the
audio stream automatically. This will work until the user (or the remote
side, which we also consider user-initiated) suspend the stream
manually.
Card profile hfgw should be no different from the rest, and thus no
internal policy inside module-bluetooth-device should decide to switch
to its profile automatically.
This should be handled by policy modules.
Handle the Playing->Connected transition gracefully by releasing the
transport and setting the sink and sources as suspended. This is
necessary since the IO thread might not encounter a HUP always.
Until today, setting the card to some profile resulted in a transport
acquisition, leading to audio stream setup. This is generally not very
interesting and even undesireable for HFGW use-cases, where the
Gateway role (the remote end) would typically request the SCO link.
Nevertheless, there is no safe way to implement such check without race
conditions, since the BlueZ's state can change between the state report
and the call to Acquire(). The chances for this to reproduce are quite
low though, since interface state changes are relatively slow.
This race condition requires that BlueZ's API is extended in order to
perform the operation atomically, which has already been discussed and
ack-ed in the BlueZ mailing list.
Note that this patch does not introduce a new race condition, since it
already existed before (the PropertyChanged->Acquire race condition,
affecting HFGW use-cases). It is just more explicit now.
If the acquisition of the transport fails, the profile should still be
set. In this case the audio is not actually streaming, so the sink and
source will be created but left suspended.
If the transport needs to be acquired later, for example because the
user wants to route the audio the remote device, the suspend flag should
have to be changed.
Use the port availability flag to expose whether a certain profile is
connected and whether it's doing actual audio streaming.
The proposed mapping is the following:
- Profile disconnected: port is unavailable
- Profile is connected (but not streaming/playing): availability unknown
- Profile is streaming/playing: port is available
The availability-unknown is specially interesting: it involves that if
the sink/source exists (corresponding card profile set), it is currently
in suspended state.
For example, for SCO cases (HFGW or HSP), this means the SCO is down. A
policy module would typically not change this, unless someone is really
trying to use the sink/source. This situation would be nicely handled by
module-suspend-on-idle, which would automatically connect SCO.
On the other hand, if the user wants to control the status of the SCO,
it will still be possible by resuming the sink or source (suspend=0).
This works out-of-the-box since most UIs would show to the user ports
whose availability is unknown.
The configuration of the transport that depends on the MTU should be
performed every time the transport has been acquired, since the
parameters depend on what the Media API provides. This requires to
update the parameters of the sinks and sources as well.
This patch moves this code into a new function that will be called
when the stream is starting (setup_stream), from the IO thread.
This makes the code more robust, since the existing multiple calls to
bt_transport_acquire() do not rely on setup_bt() being able to acquire
the transport.
There should be one port per sink/source so a dummy set_port callback
will be enough.
Adding this callback avoid the "operation not implemented" error
message and additionally makes the module work nicely with
module-switch-on-port-available.
