This commit adds basic support for devices implementing HSP Headset
Unit, HSP Audio Gateway, HFP Handsfree Unit, HFP Audio Gateway to the
BlueZ 5 bluetooth audio devices driver module (module-bluez5-device).
The code in the "io_fail" section was only used for HUP handling, but
there were jumps to there also from places where reading or writing
failed, because the read/write failure could have been caused by HUP.
This patch simplifies things by checking for HUP condition before
trying to read or write. Now if reading or writing fails, we will
jump to "fail" directly instead of going via the "io_fail" label. As
a result, the "io_fail" label isn't needed any more.
There are several intertwined changes that I couldn't separate into
nicer commits. This is mostly just refactoring, but this also fixes
a bug: the old code set the device valid in parse_device_properties()
even if the device's adapter was invalid (had NULL address).
To improve the clarity of the code, I split the device_info_valid
variable into two booleans: properties_received and valid.
I added function device_update_valid() that checks all conditions that
affect the device validity. The function can then be called from any
place where something changes that potentially affects the device
validity. However, currently the only validity-affecting thing that
can change is the device adapter, so device_update_valid() is only
called from set_device_adapter().
I added the aforementioned set_device_adapter() function so that
whenever the adapter is set, the device validity gets updated
automatically.
The new properties_received variable allowed me to remove the
is_property_update function parameters.
This is a cosmetic change. There are a couple of places where we check
whether the adapter object is valid, and while checking whether the
address property is set works just fine, I find it nicer to have a
dedicated flag for the object validity. This improves maintainability
too, because if there will ever be more adapter properties that affect
the adapter validity, the places that check if the adapter is valid
don't need to be updated.
This name is more acurate with regards of what role we're currently
playing and we've already been using it in
pa_bluetooth_profile_to_string() since 449d6cb.
Currently the latency information is being updated based on the encoded
SBC data instead of the decoded PCM data. Fixing this required moving
the timing update to be after the packet has been decoded.
The Nokia E7 running Symbian Belle Refresh seems to generate invalid SBC
packets every few minutes. This causes pulseaudio to disconnect the
stream and log "SBC decoding error (-3)".
If a single packet is bad, pulseaudio should keep playing the stream.
I think this makes the code a bit nicer to read and write. This also
reduces the chances of off-by-one errors when checking the bounds of
channel count values.
by using pa_modargs_get_sample_rate() we avoid inconsistant validity
checking of the sample rate in various places
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
When setting attribute foo, or in this case the card profile, in my
opinion the thing passed to the set_foo() function should be of the
type of foo, not a string identifier that can be used to search for
the actual foo in set_foo().
This is mostly a question of taste, but there's at least some small
benefit from passing the actual object: often the profile object is
already available when calling pa_card_set_profile(), so passing the
card name would cause unnecessary searching when pa_card_set_profile()
needs to look up the profile from the hashmap.
When parsing device properties, missing adapter will result in
device_info_valid being set to -1. It is then logical that if the
adapter goes missing at a later point, device_info_valid gets set to
-1 also in that situation.
The function did two things: set device_info_valid to -1 and called
device_free() for each device in the hashmap. Setting
device_info_valid to -1 was unnecessary. The main purpose of that was
to fire DEVICE_CONNECTION_CHANGED as a side effect, but that hook is
fired anyway in device_free(), as a side effect of removing all
transports. Calling device_free() can be delegated to pa_hashmap, when
freeing or emptying it.
Normally DEVICE_CONNECTION_CHANGED is fired when the first transport
becomes connected, but it may happen that the first transport becomes
connected already before the device properties have been received. In
that case the hook should be fired at the time the device properties
are received. This patch makes the hook to be fired at the right time.
At this point this doesn't make any other practical difference than
making the code more logical, but in the next patch I'll fire the
DEVICE_CONNECTION_CHANGED hook in set_device_info_valid(), and at that
point it's important that the device isn't marked valid too early,
because otherwise external code would see "valid" devices that however
don't have the adapter set.
The function was redundant, because all it did was call adapter_free()
for each adapter in the hashmap, and that can be delegated to
pa_hashmap when freeing or emptying it.
Previously module-bluez5-discover and module-bluez4-discover were being
tracked using their pa_module pointer. But during daemon shutdown these
modules are unloaded before module-bluetooth-discover, leaving stale
pointers in module-bluetooth-discover's userdata. To avoid this problem
this commit makes module-bluetooth-discover keep track of
module-bluez5-discover and module-bluez4-discovery by their indexes.
Create a wrapper module called module-bluetooth-discover to avoid
breaking backward-compatibility of default.pa. This wrapper may
eventually be dropped altoghether with BlueZ 4 support.
For quite some time now the device driver module doesn't work well
without the discovery module, so for the BlueZ 5 support we'll prevent
the device driver module to be loaded if the discovery module is not
loaded.
Create the thread function, the render and push functions for A2DP, the
process message function for communication between the I/O thread and
the main thread, and other helper functions related to them.
