It's bad form to assume in free() that any member of the struct has
been initialized. I ran into problems with this when I reordered
things in pa_sink_input_new() and pa_source_output_new().
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.
This patch replaces every occurrence of '){' with ') {'.
The ffmpeg source tree was excluded since it will disappear anyways.
Command used for this:
find . -type d \( -name ffmpeg \) -prune -o \
-regex '\(.*\.[hc]\|.*\.cc\)' \
-exec sed -i -e 's/){/) {/' {} \;
This fixes a later assertion failure in module-stream-restore.
Buglink: https://bugs.launchpad.net/bugs/896602
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
idea is to allow optimized code path (similar to volume code)
and rework/specialize mixing cases to enable runtime performance improvements
no functionality changes in this patch
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
This makes sure we don't try to plug in a passthrough stream if the
final sink/source sample spec doesn't match what we want. In the future,
we might want to change rate updates to try a full sample spec update
for passthrough streams.
https://bugs.freedesktop.org/show_bug.cgi?id=50951
Misbehaving clients can try to set a filter sink to output to
itself, leading to crashes later on. This patch protects us from that.
Thanks to Roman Beslik for testing and finding an error in the first
version of this patch.
Tested-by: Roman Beslik <rabeslik@gmail.com>
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=44397
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
This allows clients to get a "fake" sample space for compressed formats
that we can support. This should make size/time conversion for things
like calculating buffer attributes simpler.
These utility functions could be handy to clients.
pa_format_info_to_sample_spec_fake() isn't made public, but the return
value is changed to keep in sync with pa_format_info_to_sample_spec().
If a *_UNLINK_POST hook causes a sink-input/source-output's sink/source
to go away, the subsequent attempt to update the sink/source status will
cause an assert. We deal with this by checking the sink/source status
before trying to update it.
Basically adds code to handle passthrough sources. This isn't a tested
path at the moment, but in the future, when we do wish to support these,
it'll save us the trouble of having to sync all the code again.
Avoid resampling or use integer resampling when supported by the
sinks/sources
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
This problem was found when tracing down a crash coming from the
esound protocol, which does not set a channel map.
BugLink: http://bugs.launchpad.net/bugs/864071
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
N.B.: As Colin notes, this is because commit 117c7145 was incomplete
("format: Fix channel map handling")
These are not used for anything at this point, but this
makes it easy to add ad-hoc debug prints that show the
memblockq name and to convert between bytes and usecs.
This makes sure that when we're traversing the device chain for sources
and sinks with shared volume, we handle the case that a sink-input or
source-output of one of these might be unlinked (while unloading a
module, for example).
After the rework to the add pa_sink_input_new_data_set_sink() (and
the source equiv) calling with a NULL sink object will hit an assert.
This caused crashes with the esd protocol and there was the potential
(albeit unlikely) for a crash when creating a sink input without any
sinks available (module-always-sink mitigates this risk but it's still
a potential crasher).
This was added to ensure symmetry between playback and recording streams
code, but in reality this makes little sense practically speaking and thus
it is removed.
This piggy backs onto the previous changes for protocol 22 and
thus does not bump the version. This and the previous commits should be
seen as mostly atomic. Apologies for any bisecting issues this causes
(although I would expect these to be minimal)
This change doesn't add any functionality in itself, but it will be useful in
the future for operating on chains of sinks or sources that are piggy-backing
on each other.
For example, the PA_PROP_DEVICE_MASTER_DEVICE property could
be handled in the core so that each virtual device doesn't have to maintain it
separately. By using the origin_sink and destination_source pointers the core
is able to see at stream creation time that the stream is created by a virtual
device, and then update that device's property list using the name of the
master device that the stream is being connected to. The same thing can be done
also when the stream is being moved from a device to another, in which case the
_MASTER_DEVICE property needs updating.
Instead of using string contents for type identification use the address
of a constant string array. This should speed up type verifications a
little sind we only need to compare one machine word instead of a full
string. Also, this saves a few strings.
To make clear that types must be compared via address and not string
contents 'type_name' is now called 'type_id'.
This also simplifies the macros for declaring and defining public and
private subclasses.
This of course makes the name 'fixed' a bit of a misnomer. However the
definitions are now like this:
fixed latency: the latency may change during runtime, but is solely
controlled by the backend, the client has no influence.
dynamic latency: the latency may change during runtime, influenced by
the requests of the clients.
i.e. fixed vs. dynamic is from the perspective of the client.