Since a given property can be single-valued, an array or (in the case of
ints) a range, clients need an API to figure out what type of value a
property holds. This adds such an API. The actual property type
enumeration is kept in the PA_PROP_* namespace and not the
PA_FORMAT_INFO* namespace so that it can later be reused for properties
generically if required.
This adds integer range/array and string array property getters to the
pa_format_info API. Corresponding tests added as well to ensure the code
is valgrind-clean.
The corresponding functions are added to map-file manually for now.
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().
This makes handling errors in getter functions more graceful, rather
than triggering warnings/asserts. Better to be less trigger-happy about
these things since this is now public-facing API.
We currently only have setters and clients need to be able to query
these values as well. The return types for these functions needed to be
changed to int since this is public API now.
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.
The documentation says we expect a comma-separate list of intended
roles, but the code splits the string on whitespaces, so this corrects
the documentation to match the implementation.
Avoid resampling or use integer resampling when supported by the
sinks/sources
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
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.
For both the headers and the library we should provide clean, three part
strings as this has been what we've previously done in the past
and some external systems apparently rely on this format. While it's not
something we've officially commented on before, there is no real advantage
to us to change it so let's not try to tidy things up too much
considering some third party apps (e.g. Skype) seem to dislike a two
part version string.
This just covers Lennart's concern over the terminology used.
The majority of this change is simply the following command:
grep -rli sync[-_]volume . | xargs sed -i 's/sync_volume/deferred_volume/g;s/PA_SINK_SYNC_VOLUME/PA_SINK_DEFERRED_VOLUME/g;s/PA_SOURCE_SYNC_VOLUME/PA_SOURCE_DEFERRED_VOLUME/g;s/sync-volume/deferred-volume/g'
Some minor tweaks were added on top to tidy up formatting and
a couple of phrases were clarified too.
This is for bits of code or API where the concepts and constructs are
extensibly the same for sinks and sources. To avoid duplication we can
simply define our structure/API and then use this enum to differentiate
the two.
