Make the PulseAudio tunnel behave the same way as a client
when it comes to figuring out how to connect to the current
PulseAudio daemon. This can be useful if you start a second
PulseAudio instance for e.g. network access.
Sometimes it would be nice to disable module-suspend-on-idle for
specific devices. For me the use case is to keep a HDMI sink running
all the time to avoid loss of audio when starting to play a stream to
the device (the HDMI receiver eats a bit from the beginning of the
stream when the device is opened). This is arguably a hacky solution
to the problem, but on the other hand, I think it's very sensible to
interpret negative timeout in the module-suspend-on-idle.timeout
property as disabling the suspending altogher. This is also how the
exit-idle-time configuration option behaves (negative value disables
automatic exiting).
I moved the property parsing from the timer restart function to the
function that creates the device_info objects, because if the timeout
is negative, we don't need to create the device_info object at all.
The old tunnel module duplicates functionality that is in libpulse,
due to implementing the native protocol, and the protocol code in
the old tunnel module tends to get broken every now and then, because
people forget to update the tunnel module protocol implementation
when changing the native protocol. module-tunnel-source-new avoids this
problem by using libpulse to communicate with the remote server.
With very low input sample rates the memory pool max block size may
not be big enough, in which case we should return the size of one
frame. Returning zero caused crashing.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=68616
This patch adds the ability to restore profiles if they are added after
card creation.
Adding profiles after card creation mainly happens for bluetooth cards.
Buglink: https://bugs.freedesktop.org/show_bug.cgi?id=65349
There is no function to load the authentication cookie for a context.
You can only set environment variables. This patch adds
pa_context_load_cookie_from_file().
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
If the sink rate is not updated, then the monitor source will appear
to have a different rate than the sink, but in reality there's never
any resampling done when moving data from the sink to the monitor
source, so it's a lie that the monitor source has a different rate.
The result of lying is that clients that capture from the monitor
source will have streams that run too fast or slow.
When a sink changes its sample rate, also the monitor source rate
needs to be changed. In order to determine whether a source supports
rate changing, the code checks if the update_rate() callback is set,
but monitor sources don't have that callback set, so the old code
always failed to change the monitor source rate.
This patch fixes the monitor source rate changing by handling monitor
sources as a special case in pa_source_update_rate(): if the source is
a monitor source, then the update_rate() callback is not required.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=66424
This adds asserts to check if the implementation has an update rate
function defined for the unlikely event that some implementation forgets
to assign a update rate function we can simply bail.
It is expected from the resampling implementations to have such a
function even if the state of the resampler is completely reset.
This patch fixes this assertion:
Assertion 'r->i_ss.rate >= r->o_ss.rate' failed at ../../src/pulsecore/resampler.c:1744, function peaks_init(). Aborting.
The pa_resampler struct contains many implementation specific
structures. These create overhead and don't belong there anyways.
This patch moves the implementation specific structures out of the
pa_resampler structure.
If a capture stream captures from a single sink input (so the capture
stream is a so called "direct on input" stream), then it needs to
connect to the monitor source of the sink to which the sink input is
connected. Previously the correct source was not figured out
automatically, causing the capture stream creation to fail.
The old tunnel module duplicates functionality that is in libpulse,
due to implementing the native protocol, and the protocol code in
the old tunnel module tends to get broken every now and then, because
people forget to update the tunnel module protocol implementation
when changing the native protocol. module-tunnel-sink-new avoids this
problem by using libpulse to communicate with the remote server.
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
The Bash shell completion for pacat --device combines the name of the
last sink and the name of the first source. This patch fixes that by
adding a whitespace separator in the list of devices.
Buglink: https://bugs.freedesktop.org/show_bug.cgi?id=68106
This makes it easier for users of this API to add/updated a volume
factor by doing a _remove_volume_factor() followed by an
add_volume_factor(), rather than having to either remember whether this
is the first set operation or have an API to query whether a factor has
already been set.
This is needed by the tunnel module rewrite, which runs pa_mainloop in
the IO thread instead of pa_rtpoll.
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
interactive sessions are initiated with a hello message in order to
receive a welcome message from the PA daemon and a command prompt
interactive sessions have a terminal connected to stdin
non-interactive sessions execute commands given on the command line
or received via stdin; non-interactive sessions have neither welcome
message nor command prompt
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
Some HD-audio codecs (at least ALC269VB and ALC283) become quite noisy on
high Mic Boost levels. So e g, if there is a "Mic Boost" and a "Capture"
control, both ranging from 0 dB to +30 dB, you get better quality if
"Mic Boost" is 0 dB and "Capture" is +30 dB, than the other way around.
By changing the order in the configuration files, this patch makes us prefer
leaving "Mic Boost" low and "Capture" high if the user selects a medium gain.
(This is based on limited experience, and there is no guarantee that there are
no sound cards that work the other way around, and therefore this patch could
potentially regress quality on those machines. Hopefully those are fewer, so
this is what we should default to.)
BugLink: https://bugs.launchpad.net/1085402
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Currently the biggest possible sink latency is 10 seconds. The total
latency of the loopback is divided evenly for the source, an
intermediate buffer and the sink, so if I want to test 10 s sink
latency, the total needs to be three times that, i.e. 30 seconds.
Usually, you want to use one input or output at a time: e g,
you expect your speaker to mute when you plug in headphones.
Therefore, the headphones+speaker port should have lower priority
and both headphones and speaker.
A practical formula to do this is 1/x = 1/xa + 1/xb + .. + 1/xn.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
We document the default values in daemon.conf, but this was not
updated when we changed the default from speex-float-3 to speex-float-1.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
