In case the local UDP port is blocked by a firewall by default, send
an initial timing packet so the connection tracking will accept the
response packages.
Otherwise, the connection will fail with an 'RTSP/1.0 500 Internal
Server Error' after some timeout.
Fixes: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/840
This patch adds the autoreconnect feature to the raop module.
This is mainly to be used in a server context, but can be used
also in a desktop usage context.
With autoreconnect feature, the raop module behaves like this:
- At initialisation or in case of the RTSP TCP connection lost, it
tries to reconnect every 5 seconds
- In case of any fatal error, it tries to reconnect every 5 seconds
- In UDP mode, if no timing packets received anymore for a long time,
RTSP connection is closed, then it tries to reconnect..
- After reconnection, once RTSP session has been established again,
playing is resumed automatically.
- When the connection is not established yet (or loss), the sink
behaves like a null sink. In the source code I called it "autonull",
even if autonull is set to autoreconnect param value, it could be
split into two different params.
This was being done automatically by autotools, now we need to manually
specify this for each executable/library with a dependency in a
non-standard directory.
Brings things in line with the autotools build, and adds ALSA mixer
paths and profile-sets into the meson build system as well.
The module installation path is also now customisable.
When reviewing another change in rsa_encrypt(), Felipe Sateler pointed
out some deficiencies in error handling. This patch adds error handling
for all openssl calls in rsa_encrypt().
This patch doesn't propagate the error all the way up to the
pa_rtsp_client owner, because there's no mechanism for doing that. I
could implement such mechanism myself, but I think it's better I don't
make such complex changes to the RAOP code, because I don't have any
RAOP hardware to test the changes. The result is that module-raop-sink
will just sit around without doing anything. I think this is still
better than having no error handling at all.
The suspend cause isn't yet used by any of the callbacks. The alsa sink
and source will use it to sync the mixer when the SESSION suspend cause
is removed. Currently the syncing is done in pa_sink/source_suspend(),
and I want to change that, because pa_sink/source_suspend() shouldn't
have any alsa specific code.
There are no behaviour changes, the code from almost all the SET_STATE
handlers is moved with minimal changes to the newly introduced
set_state_in_io_thread() callback. The only exception is module-tunnel,
which has to call pa_sink_render() after pa_sink.thread_info.state has
been updated. The set_state_in_io_thread() callback is called before
updating that variable, so moving the SET_STATE handler code to the
callback isn't possible.
The purpose of this change is to make it easier to get state change
handling right in modules. Hooking to the SET_STATE messages in modules
required care in calling pa_sink/source_process_msg() at the right time
(or not calling it at all, as was the case on resume failures), and
there were a few bugs (fixed before this patch). Now the core takes care
of ordering things correctly.
Another motivation for this change is that there was some talk about
adding a suspend_cause variable to pa_sink/source.thread_info. The
variable would be updated in the core SET_STATE handler, but that would
not work with the old design, because in case of resume failures modules
didn't call the core message handler.
This removes the symdef header generation m4 magic in favour of a
simpler macro method, allowing us to skip one unnecessary build step
while moving to meson, and removing an 11 year old todo!
This adds a port, card and profile to RAOP sinks to make it
possible to change the latency at runtime (and have it persist)
using pavucontrol or pactl set-port-latency-offset.
Also move the IP:port part of the sink name to the port name.
EAGAIN is used allover the code rather than EWOULDBLOCK
POSIX allows EAGAIN and EWOULDBLOCK to have the same value (and in fact it is)
don't check for EWOULDBLOCK
modules/raop/raop-client.c: In function ‘send_udp_audio_packet’:
modules/raop/raop-client.c:473:41: warning: logical ‘or’ of equal expressions [-Wlogical-op]
if (written < 0 && (errno == EAGAIN || errno == EWOULDBLOCK)) {
^~
modules/raop/raop-client.c: In function ‘resend_udp_audio_packets’:
modules/raop/raop-client.c:528:45: warning: logical ‘or’ of equal expressions [-Wlogical-op]
if (written < 0 && (errno == EAGAIN || errno == EWOULDBLOCK)) {
^~
Signed-off-by: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Use predefined values depending on the server, and make it configurable.
AirPlay is supposed to have 2s of latency. With my hardware, this is
more 2.352 seconds after numerous tests.
Switch from pausing/resuming the smoother to resetting it because the
smoother got stuck returning the same value after an idle/running cycle,
making latency calculation wrong.
Some modules may only be loaded once, and trying to load them
twice from default.pa makes PulseAudio startup fail. While that could
be considered a user error, it's nicer to not be so strict. It's not
necessarily easy to figure what went wrong, if for example the user
plays with RAOP and adds module-raop-discover to default.pa, which first
works fine, but suddenly stops working when the user at some point
enables RAOP support in paprefs. Enabling RAOP in paprefs makes
module-gconf load the module too, so the module gets loaded twice.
This patch adds a way to differentiate module load errors, and
make cli-command ignore the error when the module is already
loaded.
The reported latency of source or sink is based on measured initial conditions.
If the conditions contain an error, the estimated latency values may become negative.
This does not indicate that the latency is indeed negative but can be considered
merely an offset error. The current get_latency_in_thread() calls and the
implementations of the PA_{SINK,SOURCE}_MESSAGE_GET_LATENCY messages truncate negative
latencies because they do not make sense from a physical point of view. In fact,
the values are truncated twice, once in the message handler and a second time in
the pa_{source,sink}_get_latency_within_thread() call itself.
This leads to two problems for the latency controller within module-loopback:
- Truncating leads to discontinuities in the latency reports which then trigger
unwanted end to end latency corrections.
- If a large negative port latency offsets is set, the reported latency is always 0,
making it impossible to control the end to end latency at all.
This patch is a pre-condition for solving these problems.
It adds a new flag to pa_{sink,source}_get_latency_within_thread() to allow
negative return values. Truncating is also removed in all implementations of the
PA_{SINK,SOURCE}_MESSAGE_GET_LATENCY message handlers. The allow_negative flag
is set to false for all calls of pa_{sink,source}_get_latency_within_thread()
except when used within PA_{SINK,SOURCE}_MESSAGE_GET_LATENCY. This means that the
original behavior is not altered in most cases. Only if a positive latency offset
is set and the message returns a negative value, the reported latency is smaller
because the values are not truncated twice.
Additionally let PA_SOURCE_MESSAGE_GET_LATENCY return -pa_sink_get_latency_within_thread()
for monitor sources because the source gets the data before it is played.
don't ignore server port parsing errors as suggested by Hajime Fujita
Signed-off-by: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Cc: Hajime Fujita <crisp.fujita@nifty.com>
wath may be NULL, as suggested by Hajime Fujita
Coverity ID: #1398156
setting val = NULL is not needed
Signed-off-by: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Cc: Hajime Fujita <crisp.fujita@nifty.com>
