Based on HFP specs, the audio connection is independent of the active
call status, which should be managed by the ModemManager part of the
plugin.
But when using HFP AG without modem attached, e.g. during zoom meeting,
the connection will be closed after a while unless call status has been
forced to active,
cf. https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1744.
Currently and for HFP AG PTS tests requesting to get an audio connection
in 3 seconds after a call activates, this prevent to start audio
connection before starting a call.
This commit prevents to force the call status during audio (dis)connection
if a modem is available.
Get the ModemManager interfaces when the ModemManager starts after native
HFP has started.
Also add log topic to be able to select log level for modemmanager plugin
part.
Do not parse, and do not report the negotiated frame rate. It is
completely ignored. Until support for the `FrameDurationLimits`
libcamera control is implemented, ignore any and all frame rates.
This field is only used during the setup of buffers, so it can be
transformed into a local variable, but even that is not needed
because the data type can be chosen on a per-plane basis.
Make the params introspectable, use the names to configure them in
audioconvert.
Only use precomputed filters when using the defaults.
Tweak the kaiser filter alpha and n_taps based on values calculated from
stopband attenuation and transition bandwidth.
This was introduced before for some threading implementation to have
definitions for 'tss_t' and 'tss_set()' and similar, but these were
later removed, while the header was still kept.
This header doesn't exist on older systems with older glibc and is the
reason for the only patch we need to have in Chromium to make PipeWire
to build.
Refactor the IR loading code, Make some generic open/load/close
functions and handle the different filenames in the open call.
This makes it possible to reuse some of the delay and alloc code.
It also makes it easier to add new IRs loading code.
Support /IR:<rate>,<value1>,<value2>,... as an inline IR definition.
Flush errqueue for iso-io also from the media-source handler, to avoid
dropping packet tx reports.
This applies to bidirectional streams. The sink/source handlers poll on
different fd, one being dup'd, and epoll does not trigger them in any
specific interleaved order.
`libusb_free_device_list()` should be passed `true` as its second
argument to unreference every single device in the list.
Fixes: 5e0b63b149 ("bluez5: backend-native: use quirks + usb adapter caps for checking msbc")
`dbus_connection_register_object_path()` does not take ownership of the
path passed to it, so currently the callers `telephony_{ag,call}_register()`
leak a copy of the path string. Fix that by not making an unnecessary copy.
Fixes: b28399ac57 ("bluez5: add telephony D-Bus service implementation")
We need at least a default value and the default value as a possible
value.
For enum type in the PropInfo we usually list just the basic type and
then use labels to list alternatives.
SPA_POD_CHOICE_ENUM_Int must always take at least 2 values as first one
is default. (Just 1 value no longer works on current master, and it's
anyway incorrect.)
Replace with just SPA_POD_Int, as there's just one choice.
In the unknown form-factor case (which I saw on a set of headphones
here, Creative Zen Hybrid Pro), let's avoid an apocryphal acronym in
favour of a term that might be more familiar to the user.
Instead of always renegotiating a new format and buffers when the
driver changes, only renegotiate when the converter notifies us
of an EnumFormat change. It's possible that changing the driver does
not actually change the result of EnumFormat and then we would simply
renegotiate to the same format and buffers for nothing.
In the audioconvert, check if the target_rate of the new driver has
changed. We keep the last value in our own clock so that we don't
renegotiate when we are removed from a driver (which sets our own
clock as the position). The target rate influences the result of the
EnumFormat params when we are resampling and so we need to emit a
EnumFormat change.
Parse the audio.position spec completely so that we have the right
number of channels but only store the first max_position channels.
Also rename some field to make it clear that this is about the max
number of channel positions.
Add a function that accepts the size of the position array when reading
the audio positions. This makes it possible to decouple the position
array size from SPA_AUDIO_MAX_CHANNELS.
Also use SPA_N_ELEMENTS to pass the number of array elements to
functions instead of a fixed constant. This makes it easier to change
the array size later to a different constant without having to patch up
all the places where the size is used.
Disabling dB volumes for max_dB < 0 was added in Pulseaudio in 2021,
based on a device which had -128..-127.07 range. However, negative
max_dB is valid value for USB devices, and there are devices that have
it.
Eg. Microsoft LifeChat LX-3000 has
numid=6,iface=MIXER,name='Speaker Playback Volume'
; type=INTEGER,access=rw---R--,values=2,min=0,max=151,step=0
: values=150,150
| dBminmax-min=-28.37dB,max=-0.06dB
and the dB range seems to be OK. Web search for "The decibel volume
range for element" also gives other hits with seemingly OK looking
ranges.
Don't disable dB volume unless both the max is negative and the range is
suspiciously small. This should still disable it for the device this
check was originally added for.
Link: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/447
Link: 10ac01a206
Some ALSA devices have minimum HW volume value that is muted. ALSA
indicates it with SND_CTL_TLV_DB_GAIN_MUTE = -9999999 dB/100 volume dB.
When rounding down to HW volume, we may get this muted value.
When determining splitting of volumes to mixers and soft volume, we
don't want HW mixers to set volume to muted, unless the target volume is
actually muted.
Fix by adding element_ask_unmuted_dB_vol() that rounds up if the asked
rounding mode resulted to mute.
This fixes mic getting muted at low volume despite ALSA reporting the dB
values correctly.
Fixes#4890
Move accounting for pending ISO packet to the reference time. Make sure
rate matching is reset on start, and reset matching on resync properly.
Allow resync on first cycle, ok since iso_io->now is valid immediately.
