This is useful for implementations that do hardware offloading of the
SCO audio channel and need to communicate state information to the
hardware (at least).
Start call id at 1 as for the index calls in HFP, and move this id
to spa_bt_telephony_[ag|call] so they can be used by CLCC to retrieve
the related call.
if enhanced call status is supported, send AT+CLCC on +CIEV events to
get the calls information.
The HF should declare the features supported before trying to send
related AT commands.
It should only send AT+CHLD related commands if the remote AG supports
them.
On some phones (at least), sending AT+CHLD=0 while there is no held
call returns an error. Make sure we don't do this to avoid returning
an error on D-Bus when in fact hangup_all actually succeeds.
This commit implements the dial, answer and hangup callbacks to manage
call when connected to HFP AG device.
This adds +CLIP support to be able to get remote party phone number.
Deprecate the `always-copy` property in pipewiresrc and use the new
property `use-bufferpool` in both pipewiresrc and pipewiresink to
specify whether to use the gstpipewirepool or not.
The gstpipewirepool is used for video by default unless `use-bufferpool`
is set to `false` and it is not used for audio by default unless
`use-bufferpool` is set to `true`
Setting a format does not automatically mean making a wav file.
Instead, check for the extension on the output file name and when we
can't find any good containet, use the same as the input file.
This makes more sense than doing `spa-resample test.flac -r 44100 test.wav`
and ending up with a FLAC file named test.wav. Or
`spa-resample test.flac -r 44100 -f s16 test2.flac` and ending up with a
wav file named test2.flac.
During negotiation, ensure that possible_caps exists before calling
gst_caps_intersect_full(). Sometimes possible_caps seem to be NULL which
cause the GST_IS_CAPS assert to fail.
The reason for the occasional NULL possible_caps during initial
negotiation is unknown, but this is also possible during renegotiation.
The handle_format_change() may be triggered before the next create(),
win which case we have not yet discovered in the streaming thread that
we are in the NOT_NEGOTIATED state. We should guard against this
possibility as well.
Because we don't know the stream state at the start of streaming, if
clients are deciding to connect on the basis of this flag, they will
never connect if we default to true. So let's be optimistic by default
and we'll find out on timeout if there actually isn't data to receive.
Some of the tools would like to connect to the manager socket first
because they are manager style apps. They however completely ignore any
of the configured sockets in the config and assume everything is the
default.
Fix this by adding a remote.intention = "manager" to those apps. This
instructs the protocol to first try to connect to a socket with the
-manager extension before attempting the regular configured socket.
This makes things work when you have sockets configured in /tmp
and have remote.name = /tmp/pipewire-0 in the config.
We use the remote name as a suffix for the default server address and so
it should not contain any slashes. Take everything after the last slash
if there is one.
We keep on calling the drain event for as long as we are drained. The
application is supposed to inactivate the stream or provide more data
at some point.
Because we do this from the data thread, we use a non-blocking invoke.
If for some reason the event callback takes a long time we might place a
lot of these invoke calls into the invoke queue, which will then be
dispatched one after another (and cause more blocking or a burst of
useless invoke calls).
Avoid this by only placing one drain invoke call into the queue at a
time.
Fixes#4529
If a provider uses the stream API and pushes a buffer to the stream
after the stream is set to paused, the buffer_id of the last buffer
remains in the io.
If a consumer starts streaming in this state, the buffer_id of the old
buffer is still in the io. The consumer receives a stale buffer_id and
may discard the buffer. Now the buffer is lost, since it is still marked
as busy on the producer.
This can be reproduced by starting Weston with the PipeWire backend and
repeatedly restarting a GStreamer pipeline that connects to the Weston
output. Eventually Weston won't be able to dequeue buffers since the
lost buffer is still busy.
Clear the buffers in the io when the buffers are cleared to avoid
sending an old buffer_id to the consumer.
The videoadapter always exposes the EnumPortConfig parameter. If no
converter is loaded, the EnumPortConfig parameter doesn't return a
parameter.
In this case, the client-node in the PipeWire server returns -ENOENT for
the EnumPortConfig, which in turn causes WirePlumber to fail the object
activation and it won't be able to create a link for the object.
This happens since Commit b57375ba85 ("stream: enable videoadapter in
all cases"), since now the videoadapter is always added. Before that,
the EnumPortConfig parameter was just not exposed and linking worked.
Running another client that ignores the error codes for missing
parameters (e.g., pw-dump) hides the issue, as the EnumPortConfig result
is cached as successful with 0 parameters and accessing the cache
doesn't return an error code.
Return the same PortConfig for EnumPortConfig as for PortConfig to fix
this.
