Hi
On 01. 04. 2018 13:22, Sherif Omran wrote:
i created a thin linux image using yocto and i have pulseaudio in the
system being installed. But when i start it manually, i get
pulse is not intented to start as root. I tried to enable the spawn but
even it has not been solved. I have systemv, do
On 20.03.2018 13:27, Raman Shyshniou wrote:
Currently the pipe-source will remain running even if no
writer is connected and therefore no data is produced.
This patch prevents this by auto-suspending source
when all writers are disconnected.
The series looks nearly good now, only two small comm
On 20.03.2018 13:27, Raman Shyshniou wrote:
Currently pipe-source doesn't track frame boundaries while posting
data. This can lead to assertion failure in source-output for any
sample specs except s8/u8 mono. The simplest way to reproduce is
to write s24le format to pipe:
$ pacat -r -d null --for
Dear Tanu,
thanks for your comments. My answers to individual questions are in-line
below.
In general I think there's a question of how heavy a wrapper the
"module-echo-cancellation" is supposed to be around the webrtc code. The
upstream is very actively reworking large parts of the code. Most
l
On 08.04.2018 12:23, Tanu Kaskinen wrote:
The suspend-sink and suspend-source documentation for pacmd was quite
terse, so I copied the more complete documentation from pactl. I
couldn't resist doing some other minor edits along the way too.
Bug-link: https://bugs.freedesktop.org/show_bug.cgi?id=
The current null-source implementation has several bugs:
1) The latency reported is the negative of the correct latency.
2) The memchunk passed to pa_source_post() is not initialized
with silence.
3) In PA_SOURCE_MESSAGE_SET_STATE the timestamp is always set
when the source transitions to RUNNING
sco_process_render does not unref the memblock when it encounters an error.
This patch fixes the issue. It also changes the return value to 1 in the case
of EAGAIN. Because the data was already rendered and cannot be re-sent, we
have to discard the block.
---
src/modules/bluetooth/module-bluez5-d
Currently the PA bluetooth code calls source_push() for each HSP source packet.
The default HSP MTU is 48 bytes, this means that source_push() is called every
3ms, which leads to increased CPU load especially on embedded systems.
This patch adds a hsp_source_buffer_msec argument to module-bluez5-d
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.
--
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 us
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 unsusp
This series fixes the latency calculations for module-tunnel-sink and
module-combine-sink. In some situations, both modules did not take into
account all components that contribute to the latency which lead to
jumps in the reported values.
Additionally, module-tunnel used a fixed latency of 250ms
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
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.
---
src/modules/module-combine-sink.c | 5 +++--
1 file changed,
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
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:
This patch set adds a new time smoother to PA, which delivers higher
precision than the current version. More details in the commit message
of the first patch.
The first patch adds the functionality, the other patches are a
straight forward addition of the new smoother functions to all
callers of
---
src/modules/alsa/alsa-sink.c | 86 --
src/modules/alsa/alsa-source.c | 67 ++--
2 files changed, 146 insertions(+), 7 deletions(-)
diff --git a/src/modules/alsa/alsa-sink.c b/src/modules/alsa/alsa-sink.c
index eb79a444..d2e
---
src/pulse/internal.h | 10 ++
src/pulse/stream.c | 52 +++-
2 files changed, 61 insertions(+), 1 deletion(-)
diff --git a/src/pulse/internal.h b/src/pulse/internal.h
index 01d2b6e4..0d18aa71 100644
--- a/src/pulse/internal.h
+++ b/src/
---
configure.ac | 7 +++
1 file changed, 7 insertions(+)
diff --git a/configure.ac b/configure.ac
index b0855a46..57cb3a92 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1399,7 +1399,14 @@ AS_IF([test "x$os_is_win32" != "x1"],
AS_IF([test "x$ax_pthread_ok" = "xyes"],
AC_DEFINE([_POSI
This is untested.
---
src/modules/module-esound-sink.c | 51 +++-
1 file changed, 50 insertions(+), 1 deletion(-)
diff --git a/src/modules/module-esound-sink.c b/src/modules/module-esound-sink.c
index 5ff04516..52bfa496 100644
--- a/src/modules/module-esound-si
---
src/modules/bluetooth/module-bluez5-device.c | 57 ++--
1 file changed, 53 insertions(+), 4 deletions(-)
diff --git a/src/modules/bluetooth/module-bluez5-device.c
b/src/modules/bluetooth/module-bluez5-device.c
index d40bbb0c..935ee2ce 100644
--- a/src/modules/bluetoot
---
src/modules/module-combine-sink.c | 52 ---
1 file changed, 48 insertions(+), 4 deletions(-)
diff --git a/src/modules/module-combine-sink.c
b/src/modules/module-combine-sink.c
index 79b4c6d9..1e719f8f 100644
--- a/src/modules/module-combine-sink.c
+++ b/sr
---
src/modules/module-tunnel.c | 72 +++--
1 file changed, 69 insertions(+), 3 deletions(-)
diff --git a/src/modules/module-tunnel.c b/src/modules/module-tunnel.c
index 2068deca..99aba68c 100644
--- a/src/modules/module-tunnel.c
+++ b/src/modules/module-tu
This is untested.
---
src/modules/raop/raop-sink.c | 40 +++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/modules/raop/raop-sink.c b/src/modules/raop/raop-sink.c
index ec6f8262..5103e8e7 100644
--- a/src/modules/raop/raop-sink.c
+++ b/src/m
This is untested.
---
src/modules/module-solaris.c | 43 +++
1 file changed, 43 insertions(+)
diff --git a/src/modules/module-solaris.c b/src/modules/module-solaris.c
index 240ed855..4642446a 100644
--- a/src/modules/module-solaris.c
+++ b/src/modules/modul
This is a re-base of the remaining patches from the loopback series
I sent in February 2017. There are no major changes to the series.
Georg Chini (10):
loopback: Do not detect underruns during initial latency adjustments
loopback: Limit controller step size to 2.01‰
loopback: Optimize adapt
Currently module-loopback detects underruns even if sink_input_pop_cb()
was not yet called twice and initial latency adjustments are active.
This leads to unnecessary rewind requests.
This patch delays detecting underruns until the initial adjustments
are done.
---
src/modules/module-loopback.c |
A Kalman filter is added to further reduce noise. The Kalman filter needs a
latency prediction as input, so estimate the next expected latency as well.
Again, theory is at
https://www.freedesktop.org/software/pulseaudio/misc/rate_estimator.odt
---
src/modules/module-loopback.c | 67 +++
The current loopback controller can produce a rate jump of up to 1% at startup,
which may be audible. To prevent large initial jumps, a second controller is
introduced, which produces a rate, that is not more than 2‰ away from the last
rate. Only during the startup phase, the rates produced by this
The current code assumes that the time domains of source and sink are
equal. This leads to a saw-tooth characteristics of the resulting end
to end latency.
This patch adds an iterative calculation of an optimum rate which accounts
for the difference between the source and sink time domains, thereby
Add a log_interval parameter to control the amount of logging. Default is
no logging. Like for adjust_time, two parameters exist: log_interval specifies
the interval in seconds while log_interval_msec is in ms.
If the log interval is too small, logging will occur on every iteration.
---
src/module
The previous patch slows down initial convergence. Therefore do not use
the controller weight until we can assume that we reached an equilibrium.
Because it takes some time before the reported latency values are reliable,
assume that a steady state is reached when the target latency has been
crosse
---
src/modules/module-loopback.c | 34 +++---
1 file changed, 23 insertions(+), 11 deletions(-)
diff --git a/src/modules/module-loopback.c b/src/modules/module-loopback.c
index 19a40b89..1db39ef4 100644
--- a/src/modules/module-loopback.c
+++ b/src/modules/module-loop
For USB devices the latency jitter strongly depends on device latency. Therefore
a boolean low_device_latency parameter is introduced to half the device latency.
Normally 1/3 of the configured end-to-end latency is used, with the parameter
this is changed to 1/6. In many situations the parameter ca
In many situations, the P-controller is too sensitive and therefore exhibits
rate hunting.
To avoid rate hunting, the sensibility of the controller is set by the new
parameter
adjust_threshold_usec. The parameter value is the deviation from the target
latency in usec
which is needed to produce a
A new parameter is introduced to allow specifying smaller adjust_time values
than 1s. This may be useful for a better latency control, although with alsa
devices and the current smoother code no improvement could be found.
This patch also changes the default adjust time to 1s, the old value of 10s
The patch also adds some API documentation.
---
doc/messaging_api.txt| 15 ++
man/pactl.1.xml.in | 7 +++
man/pulse-cli-syntax.5.xml.in| 7 +++
shell-completion/bash/pulseaudio | 5 +++--
shell-completion/zsh/_pulseaudio | 2 ++
src/pulse/intro
This patch adds a small message handler to the core which enables
clients to list available handlers via the list-handlers message.
Command: pacmd send-message /core list-handlers
pactl can be used with the same parameters.
The patch also introduces a convention for the return string.
It consists
This is a re-base of the messaging patches. It does not contain
changes. The first two patches have already been reviewed, I
nevertheless included them for completeness.
Georg Chini (8):
core: add simple message interface
protocol-native: add message sending capability
pactl, pacmd, cli-comm
For better readability, "pactl list message-handlers" is introduced which
prints a formatted output of "pactl send-message /core list-handlers".
The patch also adds the functions pa_message_param_split_list() and
pa_message_param_read_string() for easy parsing of the message response
string. Becau
This patch adds a new feature to the core which allows to send messages
to objects. An object can register/unregister a message handler with
pa_message_handler_{register, unregister}() while a message can be sent
to the handler using the pa_message_handler_send_message() function.
A message has 4 a
---
doc/messaging_api.txt | 5 ++
src/map-file | 4 +
src/pulse/message-params.c | 202 +
src/pulse/message-params.h | 12 +++
4 files changed, 223 insertions(+)
diff --git a/doc/messaging_api.txt b/doc/messaging_api.txt
index d0
See doc/messaging_api.txt for the added functions. All read functions
return 1 on success, 0 if end of string is found and -1 on parse error.
Additionally, for the numeric/boolean read functions, 2 is returned if
the list element is empty.
---
doc/messaging_api.txt | 15 +++-
src/map-file
The patch adds the possibility to escape curly braces within parameter strings
and introduces several new functions that can be used for writing parameters.
For writing, the structure pa_message_param, which is a wrapper for pa_strbuf
has been created. Following new write functions are available:
This patch adds the PA_COMMAND_SEND_OBJECT_MESSAGE command to protocol-native
so that clients can use the messaging feature introduced in the previous patch.
Sending messages can in effect replace the extension system for modules. The
approach is more flexible than the extension interface because
---
src/pulsecore/message-handler.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/src/pulsecore/message-handler.c b/src/pulsecore/message-handler.c
index 75310667..a983e136 100644
--- a/src/pulsecore/message-handler.c
+++ b/src/pulsecore/message-handler.c
@@ -23,6
---
man/pactl.1.xml.in | 2 +-
src/utils/pactl.c | 20
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/man/pactl.1.xml.in b/man/pactl.1.xml.in
index 66c0bda9..5279791b 100644
--- a/man/pactl.1.xml.in
+++ b/man/pactl.1.xml.in
@@ -254,7 +254,7 @@ License along w
This patch extends the client subscription API, so that signals sent from
PulseAudio can be processed. Within PulseAudio, a signal can be emitted
using pa_signal_post(). The interface can be used to notify the client of
events that are not covered by the subscription API (for example a button
press
This patch set adds signal sending capability to the core. This is
used to send signals when message handlers are added/removed or
when the description changes.
This patch set depends on the messaging patch set.
Georg Chini (3):
protocol-native: Add signal receiving capability
pactl: Add sign
This patch adds a card message handler which will be used to enable
or disable jack detection on a per port basis. Only the necessary
variables and functions are added without changing functionality.
---
src/pulsecore/card.c| 129 +++-
src/pulsecore/
This patch set uses the message API to implement messages that can
control jack detection and port availability. Jack detection can be
switched on and off for individual ports or whole cards. The current
port state can be queried.
Additionally, a port can be forced to some state. This implies
swit
With this patch, messages can be sent to the cards to enable/disable
jack detection for the whole card or single ports, manually set a port
state and to retrieve the current state of jack detection and port
availability.
---
doc/messaging_api.txt| 22
src/modul
Because ports with disabled jack detection are set to availability
unknown by default, available ports should be preferred over ports
with unknown availability.
---
src/pulsecore/core.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/src/pulsecore/core.c b
54 matches
Mail list logo