Instead of using PA_SCACHE_ENTRY_SIZE_MAX, the size for FRAME_SIZE_MAX_ALLOW is
set directly to the same value. This removes the need for the core-scache.h
include, which caused an unwanted dependency of libpulsecommon on libpulsecore.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=41539
Without this fix, errors about previous definitions are generated in
numerous locations.
Example of error:
CC libpulsecore_1.98_la-auth-cookie.lo
In file included from ../../src/pulsecore/source.h:46:0,
from ../../src/pulsecore/sink.h:40,
from ../../src/pulsecore/core.h:50,
from ../../src/pulsecore/shared.h:25,
from ../../src/pulsecore/auth-cookie.c:33:
../../src/pulsecore/device-port.h:40:24: error: redefinition of typedef
'pa_core'
../../src/pulsecore/core.h:29:24: note: previous declaration of
'pa_core' was here
make[3]: *** [libpulsecore_1.98_la-auth-cookie.lo] Error 1
Overall it would be nicer if we could avoid this kind of fix, but it
would require further reorganisation that I'm not prepared to undertake
right now.
The recommended way of setting available status is to call
pa_device_port_set_available, which will send a subscription event
to the relevant card. It will also fire a hook.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
This forms the base for being able to expose all ports of all
profiles (even inactive ones) to clients.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Since both cards and sinks can hold references to a port, it makes
sense to reference count them. Although no current implementation
actually has sinks with ports but without a card, it felt wrong
to make it harder to make such an implementation in the future.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
This makes handling of echo-cancel streams (and potentially other
filters that need to work with multiple streams) cleaner. We do this by
adding the ability to apply filter on a group of streams rather than
always treating streams individually.
This is required, for example, when changing the input source for an
echo-cancel source output. When this happens, we want to change the
module-echo-cancel instance to actually cancel between the new source
and old sink.
To do this when one stream in a group moves, we create a new filter
instance between the current master sink/source pair and move the
relevant streams to the virtual sink/source from this new instance.
This moves out code from module-stream-restore and makes an internal API
out of it to get a "stream group" for a given sink input or source output.
This is factored out for reuse in module-filter-*.
The stream group basically provides some means of attaching a logical
identification to the stream (by role, application id, etc.).
When autoloaded, it is expected that module-filter-apply (or whatever is
loading us) will take care of applying the filter on the correct
sink/source master. Instead of adding complexity by tracking what is
currently being filtered, we just disallow filtering anything except the
original master sink/source and let module-filter-apply or whatever is
loading us deal with dynamic sink/source changes.
This makes what devices are being cancelled clearer in the UI (at the
cost of being somewhat less clear when multiple devices of the same name
are plugged, but at least that's a much smaller set than everyone).
In pa_create_stream_callback, a stream is inserted into
s->context->record_streams only if it's a record stream. Otherwise it's
inserted into s->context->playback_streams. However, in stream_unlink the
stream is removed from s->context->playback_streams only if it's a playback
stream and otherwise it's removed from s->context->record_streams.
Thus, if the stream is an upload stream, we first insert it into
s->context->playback_streams in pa_create_stream_callback and then try to
remove it unsuccessfully from s->context->record_streams in stream_unlink. This
means that we are leaking hashmap entries until the context is freed,
constantly consuming more memory with applications that upload and unload a
large number of samples through one context.
Of course, this begs the question whether upload streams even belong in either
of those hashmaps. I don't want to mess around with the code too much at this
point though, so this patch should be a sufficient improvement.
This adds some infrastructure for canceller implementations to also
perform acoustic gain control. Cancellers now have a couple of new API
calls that allow them to get/set capture volume.
This is made slightly complex by the fact that cancellation happens in
thread context while most volume mangling needs to be done in main
context. To deal with this, while getting the volume we save source
volume updates as they are propagated to thread context and use this
cached value for queries. To set the volume, we send an async message to
main context and let that set the source volume.
This updates corked streams' resamplers when switching sample rates on a
sink/source, which means the restriction of allowing sample rate updates
only when no streams are attached to a sink/source is now relaxed to
preventing updates only when there is a running stream attached.
The purpose of this command is to print all the internal volume
variables for sinks/sources and all corresponding
sink-inputs/source-outputs to make debugging and reasoning about
volume-related issues easier.
This adds a boolean module parameter to disable automatic dynamic
latency readjustments on underruns, but leaves automatic dynamic
watermark readjustments untouched.
