Move the function to the utility library where the enum is defined. At
same time avoid using the default clause in order to make sure the
compiler will complain if the enum type gets extended.
Similarly to the microphone gain, the speaker gain can be abstracted
inside the transport object, even though the actual D-Bus interface in
BlueZ differs.
The microphone gain represents the volume of the incoming audio stream
from the headset. This can be nicely abstracted inside the transport
object in bluetooth-util, so the modules don't have to take care about
the D-Bus details.
memcpy() of the null implementation's run() copied data for only one
channel. Set the number of channels to 1 in init() in order to guarantee
this.
Signed-off-by: Stefan Huber <s.huber@bct-electronic.com>
Acked-by: Peter Meerwald <p.meerwald@bct-electronic.com>
apply_diff_time() fails when dropping bytes from the playback stream
and the sample spec of sink and source differ as source's sample spec is
used. Fix this by using sink's sample spec.
Signed-off-by: Stefan Huber <s.huber@bct-electronic.com>
Acked-by: Peter Meerwald <p.meerwald@bct-electronic.com>
This module works pretty similar to the module-role-cork.
It should be used as an alternative to that module. Basically
it decreases the volume of the streams specified in ducking_roles
in the presence of at least one stream specified in trigger_roles.
Also, it's possible to choice the volume that will be used in the
ducking streams and if it should operates in all devices or not.
For basic reference: http://en.wikipedia.org/wiki/Ducking
Move the connection of sink/source-related hooks to module
initialization and shutdown, to group all of them together. There is
no need to connect them every time the card profile is changed.
The hook is now deprecated so avoid using it and instead use the
recently introduced PA_BLUETOOTH_HOOK_TRANSPORT_STATE_CHANGED which also
reports the disconnection event.
Add the transport-handling hooks to the centralized list of hooks in
pa_bluetooth_hook_t. These are intended to replace the now deprecated
transport-specific hook list in pa_bluetooth_transport_hook_t.
Transport objects have an associated state even though it's not
explicitly exposed in BlueZ's D-Bus API (prior to 5.0). Instead, the
state is implicitly represented in the profile-specific D-Bus interface
(i.e. org.bluez.Headset, org.bluez.AudioSink, etc.) but it can be
convenient that bluetooth-util would abstract this separation.
The old implementation is limited to parsing the profile state, but
the D-Bus API actually exposes many more properties that are currently
not being considered, specially within org.bluez.Headset.
Centralize the Bluetooth hooks in one single place, starting with
the device hooks, while removing the duplicated ones (in this case
PA_BLUETOOTH_DEVICE_HOOK_REMOVED).
The hook PA_BLUETOOTH_HOOK_DEVICE_CONNECTION_CHANGED gets fired also
when a device is being removed, so there is actually no need to have
this duplicated hook.
Devices will have zero or one transports per profile, and besides the
typical lookup is also profile-based. Therefore, replace the old hashmap
(which used the transport path as key) with a simple array which holds
a transport pointer per profile.
Path-based transport lookups are required in a discovery basis, before
the associated device is known. Therefore, it makes more sense to
maintain a hashmap in the discovery structure itself, instead of
iterating all devices.
The code can be simplified since it's just trying to round the result of
the division. Note that the resulting behavior is slightly different,
specially when the volume is 0. In this case, it will remain at 0,
instead of being set to 1.
Transports always have an associated device, so add the pointer as a
member to the structure, and remove the discovery pointer since it
already exists in the device object.
d->hfgw_state is just another profile that should be considered exactly
as the rest inside device_audio_is_ready(), which is being used to
decide if the discovery hook gets triggered.
Therefore, there seems to be no reason to make an exception for this
profile and skip checking if the condition d->audio_state !=
PA_BT_AUDIO_STATE_INVALID holds true.
This change makes no practical difference but delaying the load of the
module also for HFGW until Audio.State is received. The benefit is
that the behavior and the code are more consistent across profiles.
I was looking at a log that showed that a suspend happened (at
a strange time), but the log didn't tell me why the suspend was done.
This patch tries to make sure that that won't happen again.
With BlueZ 5 it is possible to have profile registered by a third party
process which does not share the same bus id as bluetoothd so it is
necessary to store the sender of the transport to be able to talk to it.
Note that this is backward compatible.
In some cases (typically during pairing) UUIDs might be reported by
BlueZ incrementally, that is, as soon as they have been discovered. At
this point module-bluetooth-device might already be loaded, so the late
UUID announcements need to be handled and additional card profiles
might need to be created accordingly.
A left over "required-any" made this path useless for most people.
While we're at it, also add "Front Headphone" like for the normal
speaker path.
Tested-by: Colin Guthrie <gmane@colin.guthr.ie>
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
If we expose this information, UIs can use this to make better
decisions about what icon to display.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Added Dell Inspiron 3420, 3520 and Vostro 2420, 2520.
Note that this is only necessary for kernels 3.3 to 3.5, as 3.6
has phantom jack support.
BugLink: https://bugs.launchpad.net/bugs/1076840
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
We inadvertantly stopped supporting non-standard rates when the
passthrough work was done. This makes sure that if no standard rates are
supported, we try to fallback to whatever ALSA gives us.
The sink can be resumed while the source is still in PA_SOURCE_INIT.
This is the case if a module such as module-stream-restore routes the
audio to the sink during pa_sink_put(), leading to an inconsistent
state: the sink stays RUNNING but the transport is not actually
acquired.
When a headset is having a profile switch, we can either leave the
SCO state unmodified (as it was before this patch) or we can
alternatively request it (as older versions of PA).
This patch tries to avoid a potential regression in case a module
such as module-suspend-on-idle is not present, due to the provided
resume-on-running policy. Without this patch, and without such a policy,
the sink and sources would stay suspended until the user manually
performed another profile switch (i.e. hsp->off->hsp).
There are several other solutions currently being discussed as a longer
term solution, some of which require extendind the core. This patch is
therefore proposed as a short-term workaround to avoid the regression.
