The new helper function makes it easier to check whether any audio
profiles are connected. That information is needed by the discovery
module for deciding whether a new device module should be loaded. The
device module should use this information too to unload itself at the
right time, but that's currently not implemented.
Use a more accurate name for the function since it doesn't just check
if it is an audio device (which can be detected quite early), but it
also checks if the most relevant properties (device info, etc.) have
been received.
Besides, add the const qualifier to the pointer since it's not going to
be modified.
The Device.Connected was only used for tracking whether a device module
should be loaded, but that information is already included in the
individual profile state properties. The property can therefore be
completely ignored without any loss in functionality.
Stream-restore DBus API method argument list is missing last boolean
argument apply_immediately, causing assert to fail in AddEntry handling.
Signed-off-by: Juho Hämäläinen <jusa@hilvi.org>
Since some devices can be chatty with regards to how often they return
from poll(), this adds a PA_UNLIKELY() to all the the rewind_requested
checks in our sink modules to make the general case (no rewind was
requested) the fast path.
When a rewind is requested on a sink input, the request parameters are
stored in the pa_sink_input struct. The parameters are reset during
rewind processing, and if the sink decides to ignore the rewind
request due to being suspended, stale parameters are left in
pa_sink_input. It's particularly problematic if the rewrite_bytes
parameter is left at -1, because that will prevent all future rewind
processing on that sink input. So, in order to avoid stale parameters,
every rewind request needs to be processed, even if the sink is
suspended.
Reported-by: Uoti Urpala
...over "Digital Input Source:Analog Input". It makes life a little
easier for users of Dell xps m1330.
Just an old Ubuntu delta I never upstreamed until now.
The patch was originally written by Daniel T Chen <crimsun@ubuntu.com>.
BugLink: https://bugs.launchpad.net/bugs/453966
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Based on feedback in the bug below (comments 128, 129, 131).
BugLink: https://bugs.launchpad.net/bugs/946232
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Refactor code to fetch avail, delay and timestamp values
in a single call to snd_pcm_status().
The information reported is exactly the same as before,
however it is extracted in a more atomic manner to
improve timer-based scheduling.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
The callback relies on the sample spec being finalized, which is not
true with the NEW hook.
In case you're wondering about the "hook EARLY - 1, to match before
stream-restore" comment that was not changed even though the code that
the comment concerned was changed: the comment was apparently written
at a time when module-stream-restore used the NEW hook too, and later
stream-restore has been changed to use the FIXATE hook. So, the
comment was wrong/nonsensical before this patch. Since these two
modules now use the same hook again, the comment makes sense again.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=55135
Previously thread_func() used PA_SINK_IS_OPENED() to check whether
some data should be rendered. process_render_null() used a different
check: it would return immediately if the sink was not in the RUNNING
state. This caused a busy loop when the sink was in the IDLE state,
because process_render_null() didn't update the timestamp, and
thread_func() still kept the timer active using the old timestamp.
pa_rtpoll_run() would return immediately because of the old timestamp.
This is fixed by using the same check in both thread_func() and
process_render_null(). Since the checks are the same, it's actually
redundant to have the check in process_render_null(), so it is now an
assertion.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=54779
The sink has different frame size than the sink input, so
the max_request and max_rewind values of the sink input need
to be converted when setting the sink max_request and
max_rewind values.
The conversion is already done correctly in
sink_input_update_max_request_cb() and
sink_input_update_max_rewind_cb().
Once the sink input has been routed in pa_sink_input_new(),
the sample spec and channel map have already become fixed.
The sink input and source output must use the same stream
format, because the data is copied as-is.
When module-loopback is loaded without arguments, the ss and
map variables are initialized with dummy values. This caused
a problem, because also pa_memblockq_new() was called with
the dummy values, making it work incorrectly. The base was
set to 1 instead of the real frame size, which in turn
caused alignment related crashes.
UUIDs might be announced at any time, so a hook is needed to notify any
interested module. In practice, the UUIDs are quite stable with the
exception of the pairing procedure, where the UUIDs are reported by
BlueZ as soon as they are discovered.
The IDT/Sigmatel codec driver often creates a "Mic Jack Mode" for
every mic jack, so it can change functionality between Mic and Line In.
However, as the "Mic Jack" is the standard naming, our current solution
does not make the Line In port unavailable when nothing is plugged in.
This patch makes the "Line In" port not to be created just because there
is a "Mic Jack Mode" that could be set to "Line". This makes the behaviour
consistent with e g "Dock Mic Jack Mode", "Front Mic Jack Mode" etc, where
we don't create a "Dock Line" or "Dock Mic" port either.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
modules/rtp/module-rtp-recv.c:462:8: warning: 'r' may be used uninitialized in this function [-Wuninitialized]
Signed-off-by: Peter Meerwald <p.meerwald@bct-electronic.com>
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>
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>
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.
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>
