Do not automatically switch if the bluetooth card represets a remote
device with a computer form-factor.
If the user is connecting two computers over Bluetooth they most likely
want to use a non-audio feature like file transfer or network sharing.
Automatic audio switching in these cases creates a very poor user
experience. If the user actually wants to stream audio they can manually
select the Bluetooth audio sink or source.
If a sink or a source have the device.form_factor property set to
"computer" it is a computer connected over Bluetooth, which should have
a lower priority than other sinks/sources.
The Class of Device field has a value for "computer" in its major
portion. If the remote device behind a card is a computer, the
form-factor should be set accordingly.
Just like the manpage these written out log levels should correspond to
the numerical values listed before, intead of being in the opposite
order and provoking thoughts of the relation being the wrong way around
where 0=debug and 4=error.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/647>
Requiring user to invoke send-message with correctly quoted parameters string
is not good for usability. Wrap parameters string into JSON string and try
again. If that works, log a warning use wrapped JSON string with parameters.
As an example these two commands will now invoke the same action:
pactl send-message /card/bluez_card... switch-codec '"CODECNAME"'
pactl send-message /card/bluez_card... switch-codec CODECNAME
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/648>
Check whether a Bluetooth profile is supported both by the remote device
and the local host before creating a card profile for it.
This is useful when some of the media profiles have not been registered
with bluetoothd because ex., oFono is not running and the headset
backend is not available.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/638>
The remote device list of UUIDs reflects which profiles are supported by
the remote device alone. We currently rely solely on this list to decide
if a certain card profile is supported, and thus should be created and
get connected.
This used to be accurate when the Bluetooth modules were first written,
but now BlueZ is more dynamic and local profile support can be added or
removed during runtime. The adapter's list of UUIDs is an accurate
representation of the profiles supported by the local host at a certain
moment.
This commit combines the list of UUIDs supported by remote device and
the list of UUIDs supported by the local host to determined whether a
Bluetooth profile is actually supported or not, and whether it should be
expected to get connected during device connection.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/638>
When the SCO connection is in use, if you disconnect first and then connect,
the SCO connection will occasionally fail, and the Bluetooth error code is 42
(0x2A in hexadecimal). This is usually because an error occurred when the SCO
connection was initiated, we need to try to reconnect to optimize the handling
of this problem. The log returned by the kernel is as follows:
Bluetooth: sco_connect_cfm: hcon 0000000003328902 bdaddr 40:ef:4c:0c:11:f0 status 42
Bluetooth: sco_sock_connect status is -38
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/622>
When module-combine-sink is used to create virtual surround card it is expected
that each slave channel receives data for exactly one combined sink channel.
Currently this is not the case because module-combine-sink would follow
core->disable_remixing setting. Usually this means that multiple channels of
combined sink are getting remixed into slave channel, and there is no option to
disable this behavior just for combined sink.
Improve this by implementing "remix" modarg for module-combine-sink,
default to original behavior (follow core->disable_remixing setting).
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/627>
Mainloop test uses io callback for PA_IO_EVENT_INPUT on stdin.
With glib enabled PA_IO_EVENT_INPUT translates to glib G_IO_IN event which also
matches descriptor in EOF state. While io callback does not check for EOF after
reading from file descriptor this is causing mainloop-test to repeatedly read 0
bytes once EOF is reached, rearm defer callback and spam test log.
Fix this by disarming io callback when EOF is reached in test run.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/625>
