This patch adds an alternative time smoother implementation based on the theory
found at https://www.freedesktop.org/software/pulseaudio/misc/rate_estimator.odt.
The functions were written to replace the current smoother functions nearly on
a one-to-one basis, though there are a few differences:
- The smoother_2_put() function takes a byte count instead of a sound card
time as argument. This was changed because in most places a sample count
was converted to a time before passing it to the smoother.
- The smoother needs to know sample rate and frame size to convert byte
counts to time.
- A smoother_2_get_delay() function was added to directly retrieve the stream
delay from the smoother.
- A hack for USB devices was added which works around an issue in the alsa
latency reports for USB devices.
The smoother delivers much better precision than the current implementation.
For results, see the document referenced above.
The new functions are still unused. The following patches will convert all
callers of the smoother functions so that they can use both smoother
implementations, depending on a configure option.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/55>
This patch adds a test program that generates a square wave of a given frequency,
length and sample rate. This is then resampled to another rate, rewound and the
rewound part is run through the resampler again. After that, the results of the
first and second resampler pass are compared.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/120>
This patch is in preparation of allowing virtual sinks to specify their own
max_rewind limit.
Currently pa_sink_set_max_rewind_within_thread() simply sets the value of
max_rewind and informs the sink inputs about the new value. Virtual sinks
may however provide their own limit on max_rewind.
This patch allows to query the active sink inputs for the max_rewind value
they support and sets max_rewind to the minimum supported value. This way,
the max_rewind value from the virtual sinks can be communicated to the master
sink.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/120>
This patch is in preparation of allowing virtual sinks to specify their own
max_rewind limit.
Currently, virtual sinks cannot specify their max_rewind limit, but just copy
the value from the master sink. This may not be correct, if the DSP code of the
virtual sink has limited (or no) rewinding capability.
Because the DSP code of the virtual sink is rewound in the process_rewind()
callback of the sink input, it must be ensured, that rewinding a sink input
to the master of a virtual sink is limited similar to rewinding a sink.
There are two remaining exceptions:
1) If an underrun is detected. In that case, the filter should be reset anyway.
2) When the sink input of the filter is moved and attached to the destination
sink.
The move case is handled without involvement of the implementer, so the implementer
can only receive a rewind larger than max_rewind when the filter should be reset
anyway.
All existing virtual sinks do not distinguish between reset and rewind of the
filter.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/120>
If the output implements a process_rewind() callback, the resampler delay is
not taken into account. This leads to glitches during volume changes when
source and source output rates differ.
This patch fixes the problem.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/120>
The introduction of the history queue makes it possible to implement moving
of streams without involving the implementer. Instead of dropping all data
from the render memblockq and requesting the implementer to rewrite the
data, the render memblockq is now reconstructed from the history queue.
Additionally, the render queue will be filled with silence matching the
amount of audio that is left playing on the old sink to avoid playing
the same audio twice.
This patch slightly breaks moving for virtual sinks because they do not
yet include the resampler delay in their latency reports. This will be
fixed in a different patch set.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/120>
This patch uses the two previous patches to implemnt pseudo-rewinding for the
resamplers by feeding some old data into the resampler after a reset. This is
necessary because PA is using external resamplers that do not implement
rewinding.
To get exactly the same output data from the resampler after a rewind if possible,
the matching period is calculated. This is the number of input samples that produces
an integral number of output samples. After the matching period, the resampler state
repeats. If the matching period is not too large, feeding history into the resampler
will start at a point that is a multiple of the matching period back in time. Then
the resampler will produce exactly the same samples.
The PA_RESAMPLER_MAX_HISTORY value has been replaced by PA_RESAMPLER_MAX_DELAY_USEC
and the required number of history samples is calculated from the sink input sample
rate. The number of history samples can be as large as about 12500.
This fixes glitches during volume changes when the sink runs on a rate different
from the sink input rate.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/120>
The pa_resampler_get_delay() function allows to retrieve the current resampler
delay in input samples for all supported resamplers. The return value is a double
to maintain precision when using variable rate resamplers. Because in many places
the delay is needed in usec, pa_resampler_get_delay_usec() was also supplied.
The speex resampler now skips leading zero samples to provide meaningful delay values.
In the next patch, the pa_resampler_prepare() function will be used to train the
resampler after a rewind. It takes data from a history memblockq and runs it through
the resampler. The output data is discarded.
To make this logic possible, the soxr resampler had to be converted to use variable
rate. The fixed rate version has a variable delay, therefore the logic above could
not be applied. Additionally, with fixed rate, the delay is larger than 150ms in
some situations, while with variable rate the delay is fixed and comparable to the
other resamplers.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/120>
A new memblockq is added to the sink input code to keep some history of the
input data. The queue is kept in sync with the render memblockq. The old input
data will be used to prepare the resampler after a rewind.
pa_resampler_request() and pa_resampler_result() have been changed to round
as good as possible to avoid loosing or duplicating samples during rewinds.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/120>
When sink is suspended for reconfiguration changing sample spec, upon resume
internal thread_info max_request and max_rewind are out of date and possibly
not aligned to frame size anymore.
Recalculate thread max_request and max_rewind before resuming sink.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/658>
When ICE I/O error occurs ICE connection is closed via IceCloseConnection.
This causes crash while releasing session manager connection later because
this ICE connection was initiated and is managed by session manager, and it will
attempt to close this ICE connection again.
Fix this by closing session manager connection instead.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/650>
Commit 7fd89e491 ("bluetooth: Try to reconnect SCO") introduces a call
to pa_msleep but failed to include the header, resulting in a:
../pulseaudio/src/modules/bluetooth/backend-native.c: In function ‘sco_acquire_cb’:
../pulseaudio/src/modules/bluetooth/backend-native.c:336:17: warning: implicit declaration of function ‘pa_msleep’ [-Wimplicit-function-declaration]
336 | pa_msleep(300);
| ^~~~~~~~~
(Un)fortunately this implicit declaration gets resolved at link-time,
otherwise the issue would have been caught sooner.
Fixes: 7fd89e491 ("bluetooth: Try to reconnect SCO")
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/651>
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>
Currently, module-tunnel uses the default fixed latency of 250ms as fixed
latency.
There is no reason for such a large latency. This patch adds a parameter
latency_msec to the module to set the fixed latency at load time of the
module. The parameter can range from 5 to 500 milliseconds. With this
patch, I was able to run a tunnel sink at 7ms latency without problems.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/53>
Currently module-tunnel uses only a rough estimate of the current stream
latency and reports wrong latencies in certain situations. This leads to
very inexact and unstable latency reports for the virtual sink.
This patch fixes the issue by introducing latency snapshots like they
are used in module-loopback. Because the latency reports are now correct,
the update interval for latency re-calculations can be reduced to 1s.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/53>
Currently the combine-sink uses the trivial resampler by default.
This patch changes the default to the configured resampler.
Also the default update time is changed from 10s to 1s to achieve
faster convergence and higher precision.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/53>
Currently, it takes one adjust time before the smoother is updated after an
unsuspend. Before the first update, the smoother will not be aware of the
slave sink latencies, leading to incorrect latency reports.
This patch moves the first smoother update to one latency time after the
sink was unsuspended, thereby improving initial latency reports. This
only partially resolves the problem because the smoother takes multiple
updates to adapt to the slave sink latencies.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/53>
This patch adds a rate controller similar to the one used in module-loopback
to limit step size and maximum deviation from the base rate. Rate changes
are handled more smoothly by the controller. The patch has not much impact
on the behavior of the module, except that there is less rate hunting.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/53>
Currently module-combine-sink uses only a rough estimate of the current
slave sink latencies to calculate the rate for the various sink inputs.
This leads to very inexact and unstable latency reports for the virtual
sink.
This patch fixes the issue by introducing latency snapshots like they
are used in module-loopback. It also changes the definition of the
target latency to ensure that there is always one sink which uses the
base rate.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/53>
Commit f89d64b98e fixed a crash
when disabling adapters. However, now if any device is removed
ofono card is removed, even if it belongs to different device.
Add a check for the device being unlinked to our callback to fix.
Signed-off-by: Juho Hämäläinen <juho.hamalainen@jolla.com>
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/624>
With USB Alternate Setting 3 size of HCI payload is 72 bytes which is already
larger than mSBC frame size. Largest known size of HCI payload is with USB
Alternate Setting 5 (144 bytes), make it the default SCO socket MTU.
Reserve additional space in bluetooth encoder buffer to cover this case.
Since mSBC encoder and decoder will now work with larger packet sizes, drop
assertions about MTU larger than mSBC frame size.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/617>
While the threading model for combine is different from other filters
(which expect to just piggy-back on the I/O thread of the most
downstream sink), it might still be valuable to set this field to
indicate that this sink input is intended to behave as a filter stream
rather than a conventional stream.
At the very least, routing behaviour and cycle detection should act on
these streams as with any other filter.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/399>
