In case all other profiles fail, try this fallback mapping as well.
It allows the device to specify the channel count, so it can be used
for devices that only supports being opened in multichannel mode.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
A fallback mapping or profile will only be considered for probing
if all non-fallback profiles fail.
If auto-profiles are used, a profile made up of one non-fallback
mapping and one fallback mapping will be considered a fallback profile.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Allow a mapping to relax the exact channel restriction:
exact-channels = yes | no # If no, and the exact number of channels is not supported,
# allow device to be opened with another channel count
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Remove extra-hdmi.conf, as the performance reasons behind it are invalid
Add 7.1 profiles
Add extra HDMI devices, for a total of 8
Add DTS-encoded profiles (they need dcaenc from git)
Signed-off-by: Alexander E. Patrakov <patrakov@gmail.com>
tunnel-new handled a corked stream conditional in the thread_func to be
sure the stream isn't corked. Un/Corking is now handled in the
state change callback.
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
The stream is now corked when the sink or source becomes suspended and
uncorked when it's back idle/ready.
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Since rtkit v11, the top limit for rttime is 200 ms (previously it
was wrongly limited to 2 seconds).
Reviewed-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Ricardo Salveti de Araujo <ricardo.salveti@canonical.com>
This comment can potentially save a lot of debugging effort and fixing
an ABI break, even though I don't think it's particularly likely that
anyone will ever extend pa_ext_device_manager_role_priority_info.
A recent patch broke the build on FreeBSD, which does not have
HAVE_CREDS defined. Also, make sure any attempts to enable the
srbchannel on such architectures fail.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=80642
Reported-by: Ryan Lortie
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Runs four tests:
1) Small packets, iochannel
2) Big packets, iochannel
3) Small packets, srbchannel
4) Big packets, srbchannel
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
The srbchannel is enabled if protocol version >= 30 and
SHM is available. There is also a module parameter
srbchannel=false that can be used for disabling the srbchannel.
The setup is done in these steps:
1) Server receives authentication (like today)
2) Server sends enable_srbchannel to client
3) Server sends memblock to client
4) Client receives enable_srbchannel
5) Client receives memblock
6) Client sends enable_srbchannel back to server
7) Client switches over
8) Server receives enable_srbchannel and switches over
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
This increments protocol version to v30 and adds two new commands
to enable and disable an shm ringbuffer, as well as client side
implementation.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
For writing, we prefer writing through the srbchannel if one is available,
and we have no ancil data to send.
For reading, we support reading from both in parallel. This meant replicating
a struct used for reading, so a lot of this patch is just a search/replace in
do_read to use the appropriate channel for reading.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
To keep the data and the ringbuffer separate, let's add another
mempool just for the ringbuffer(s). That way, the client can open
the ringbuffer shm file in rw mode and keep the data in ro mode.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
patch 'memblock, pstream: Allow send/receive of remote writable memblocks'
adds an extra parameter to pa_memimport_get()
change test program accordingly
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
Cc: David Henningsson <david.henningsson@canonical.com>
The shared ringbuffer memblock must be writable by both sides.
This makes it possible to send such a memblock over a pstream without
the "both sides writable" information getting lost.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
This is a preparation for the shm ringbuffer, which needs to be able
to be writable by both sides, because there are atomic variables they
both need to modify.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
An shm ringbuffer that is used for low overhead server-client communication.
Signalling is done through eventfd semaphores - it's based on pa_fdsem to avoid
syscalls if nothing is waiting on the other side.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
This patch adds support to iochannel, pstream and pstream-util
to send file descriptors over a unix pipe.
Currently we don't support writing both creds and fds in the same
packet, it's either one or the other (or neither).
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
The file descriptors are read from the iochannel just like the creds are.
So instead of passing just creds (and creds_valid), we now pass the
entire pa_ancil struct.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
To support later patches that add sending/receiving file descriptors,
let's add this struct.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
As a way to highlight warnings and errors in GCC output
This will be available in GCC 4.9, but some distros backported
the feature to lower versions
http://gcc.gnu.org/gcc-4.9/changes.html
As the automake documentation says:
AM_CPPFLAGS: The contents of this variable are passed to every compilation
that invokes the C preprocessor; it is a list of arguments to the preprocessor.
For instance, -I and -D options should be listed here
AM_CFLAGS: This is the variable the Makefile.am author can use to pass in
additional C compiler flags.
http://www.gnu.org/software/automake/manual/html_node/Program-Variables.html
The code in the "io_fail" section was only used for HUP handling, but
there were jumps to there also from places where reading or writing
failed, because the read/write failure could have been caused by HUP.
This patch simplifies things by checking for HUP condition before
trying to read or write. Now if reading or writing fails, we will
jump to "fail" directly instead of going via the "io_fail" label. As
a result, the "io_fail" label isn't needed any more.
Previously relative cookie paths were searched from the home
directory, now they are searched from the config home directory. This
fixes the problem that XDG_CONFIG_HOME didn't have effect on cookie
paths.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=75006
If a relative path is passed to pa_authkey_load(), it will interpret
the path as relative to the home directory. This is wrong, because
relative paths should be interpreted to be relative to the config home
directory. Before fixing pa_authkey_load(), this patch prepares for
the change by using absolute paths when the file actually needs to be
in the home directory (i.e. the fallback cookie path for the native
protocol and the default cookie path for the esound protocol).
The only place where pa_authkey_load() was called was in
pa_authkey_load_auto(), and the only functionality that
pa_authkey_load() was to log a warning if load() fails. That log
message is now in pa_authkey_load_auto(), so pa_authkey_load() has no
use any more.
pa_context already ignored the return value of pa_client_conf_load(),
so the only places where the return value was not ignored were the
D-Bus server lookup thing and pax11publish. I don't think those cases
are negatively affected if they ignore errors in opening or parsing
client.conf.
pa_client_conf_env() never failed anyway, so returning int was
obviously redundant.
block_usec should be determined by the sink max latency, not the other
way around. This change doesn't cause any change in behaviour, but
makes the code more logical. Further updates to block_usec are already
done correctly, so this is the only place that needs modification.
Mark the sink as DYNAMIC_LATENCY and implement update_sink_latency_range
on its sink-input to collect the combined latency range of all sinks.
Implement update_requested_latency on the sink to configure the final
latency by combining the sink-input requested latencies. This makes us
honour the client latency request.
Also add more debug log.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=47899
- Make sure "no evacuation sink/source found" is not printed when
fallback source/sink is selected
- Restore previous behaviour of fallback sink/source selected
(first one instead of last one)
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Recently met a problem: when I disconnect the bluetooth headset, the
pulseaudio automatically switch the sound to sink of HDMI output
instead of the sink of internal speaker even though there is no HDMI
cable connected.
To fix this problem, I want to change the rule of selecting the target
sink if the default sink is not available. (same rules apply to the
source selecting):
construct a new hashmap with all ports (of all relevant sinks) and
then call find_best on the new hashmap to find the best port, finally
find the corresponding sink using the best port.
Signed-off-by: Hui Wang <hui.wang@canonical.com>
