Passing a NULL-terminated array of pa_format_info pointers is a bit
unwieldy for clients. Instead of this, let's pass in an array of
pointers and the number of elements in the array.
This quite is an old patch. It was added to N900 to avoid unnecessary
wake-ups when the phone is in power save mode (= blank screen and
no user interaction). In this situation if the user had a browser
window with flash animation open pulseaudio kept waking up every
10 seconds, causing a severe hit to use times.
Anyway I do not see any reason to send timing updates if the sink or
source where the stream is connected to is suspended.
This replaces the simple string used by pa_format_info's proplist with a
JSON string (accessed via new API only). This allows us to express lists
and ranges more cleanly, and embed type information for future
extensibility.
We use json-c for JSON parsing. This is a lightweight depdency (32 KB on
my system) and avoids the hassle of having to reinvent a JSON parser.
Also included is a test which verifies functionality and is
valgrind-clean.
When the sink format changes and we kill the stream, clients need a way
to know (a) what device they should reconnect to, and (b) what the
stream running time was when the stream got killed (pa_stream_get_time()
won't work after the stream has been killed). This adds these two bits
of information in the event callback's proplist parameter.
IEC61937-encapsulated E-AC3 frames contain 6 audio blocks per substream,
which corresponds to 1536 samples contained a 24576-byte frame. To cope
with this, we maintain the s16le stereo sample spec, but quadruple the
sample rate so that the conversion remains accurate.
This event is emitted if the sink-input could not be moved to a new sink
because it doesn't support the format of the sink-input. Clients can
reconnect their stream with a different format if they wish or
gracefully exit.
We frequently need to free an idxset containing pa_format_infos, so
define an internal free function that can be used directly with this
(instead of defining it once-per-file).
This removes the passthrough flag from sinks since we will drop
exclusively passthrough sinks in favour of providing a list of formats
supported by each sink. We can still determine whether a sink is in
passthrough mode by checking if any non-PCM streams are attached to it.
This is the beginning of work to support compressed formats natively in
PulseAudio. This adds a pa_stream_new_extended() that takes a format
structure, sends it to the server (=> protocol extension) and has the
server negotiate with the appropropriate sink to figure out what format
it should use.
This is work in progress, and works only with PCM streams. Actual
compressed format support in some sink needs to be implemented, and
extensive testing is required.
More details on how this is supposed to work is available at:
http://pulseaudio.org/wiki/PassthroughSupport
This makes sure that we handle streams moving between sinks properly. To
do this, we change the way the filter.* properties are handled a little
bit.
Firstly, this splits up the "filter.apply" property into two properties
- "filter.want" and "filter.apply". "filter.apply" acts as before - it
bypasses module-filter-heuristics and directly tells module-filter-apply
what filters are to be applied.
"filter.want" is used to tell module-filter-heuristics what filters the
client wants. The module then decides whether to actually apply the
filter or not (for now, this makes sure we don't apply echo-cancellation
even if requested on phone sinks (where it is assumed AEC is taken care
of or is not required).
Next, we also make sure that we track whether the client set
"filter.apply" or module-filter-heuristics did - and in the latter case,
we recalculate "filter.apply" and then have module-filter-apply apply
the filter if required. This introduces some evil in the form of causing
the move_finish callback to possibly trigger another move, but we
protect for this case (with a property) to be doubly sure of not causing
an infinite loop.
This is pretty cosmetic change; there's no actual functionality added.
Previously the volume_writable information was available through the
pa_sink_input_is_volume_writable() function, but I find it cleaner to have a
real variable.
The sink input introspection variable name was also changed from
read_only_volume to volume_writable for consistency.
Mostly warnings about unused stuff.
Furthermore, the first hunk is a fix for the change in 177948a6.
Finally, comment in AEC_dtd was translated and the code simplified slightly.
CC module_bluetooth_device_la-module-bluetooth-device.lo
modules/bluetooth/module-bluetooth-device.c: In function ‘a2dp_process_render’:
modules/bluetooth/module-bluetooth-device.c:1335:30: warning: pointer targets in passing argument 6 of ‘sbc_encode’
differ in signedness [-Wpointer-sign]
../src/modules/bluetooth/sbc/sbc.h:92:9: note: expected ‘ssize_t *’ but argument is of type ‘size_t *’
CC module_rygel_media_server_la-module-rygel-media-server.lo
modules/module-rygel-media-server.c:383:13: warning: ‘append_property_dict_entry_object_array’ defined but not used [-Wunused-function]
CC module_echo_cancel_la-adrian-aec.lo
modules/echo-cancel/adrian-aec.h:360:15: warning: ‘AEC_getambient’ defined but not used [-Wunused-function]
modules/echo-cancel/adrian-aec.h:368:14: warning: ‘AEC_setgain’ defined but not used [-Wunused-function]
modules/echo-cancel/adrian-aec.h:374:14: warning: ‘AEC_setaes’ defined but not used [-Wunused-function]
modules/echo-cancel/adrian-aec.h:377:16: warning: ‘AEC_max_dotp_xf_xf’ declared ‘static’ but never defined [-Wunused-function]
CC module_echo_cancel_la-module-echo-cancel.lo
modules/echo-cancel/module-echo-cancel.c: In function ‘time_callback’:
modules/echo-cancel/module-echo-cancel.c:266:12: warning: variable ‘fs’ set but not used [-Wunused-but-set-variable]
CC module-virtual-sink.lo
modules/module-virtual-sink.c: In function ‘sink_input_pop_cb’:
modules/module-virtual-sink.c:206:15: warning: variable ‘current_latency’ set but not used [-Wunused-but-set-variable]
The HAVE_CLOCK_GETTIME macro protects timespec and related functions, nothing of which is used in
pa_rtclock_from_wallclock. And silently just not converting was not the proper solution anyway.
Also add an assert in pulse/mainloop.c to report the integer overflow that was triggered by the wrong
pa_rtclock_from_wallclock. Without the assert, debugging was painful.
This value is not a technical upper limit, it's just a 'sensible'
value that is not crazy high, but also allows software amplification
above 0dB (aka 100%) for very quiet audio sources.
We recommend that a comprehensive volume control UI should allow
users to set volumes up to this limit, although of course should
deal gracefully if the user has set the volume even higher than this
without resulting in a feedback loop that effectively limits the
upper volume.
The value chosen is +11dB. This was selected somewhat subjectively
and is very similar to the current 150% that gnome-volume-control
uses (which is ~+10.57dB).
On the plus side, we now recommend that everyone allows
'Volumes up to 11' which is pretty awesome.
http://en.wikipedia.org/wiki/Up_to_elevenhttps://tango.0pointer.de/pipermail/pulseaudio-discuss/2010-April/006945.htmlhttps://tango.0pointer.de/pipermail/pulseaudio-discuss/2010-April/006950.html
When we have a filter sink that does some processing, currently the
benefits of the flat volume feature are not really available. That's
because if you have a music player that is connected to the filter sink,
the hardware sink doesn't have any idea of the music player's stream
volume.
This problem is solved by this "volume sharing" feature. The volume
sharing feature works so that the filter sinks that want to avoid the
previously described problem declare that they don't want to have
independent volume, but they follow the master sink volume instead.
The PA_SINK_SHARE_VOLUME_WITH_MASTER sink flag is used for that
declaration. Then the volume logic is changed so that the hardware
sink calculates its real volume using also the streams connected to the
filter sink in addition to the streams that are connected directly to
the hardware sink. Basically we're trying to create an illusion that
from volume point of view all streams are connected directly to the
hardware sink.
For that illusion to work, the volumes of the filter sinks and their
virtual streams have to be managed carefully according to a set of
rules:
If a filter sink follows the hardware sink volume, then the filter sink's
* reference_volume always equals the hw sink's reference_volume
* real_volume always equals the hw sink's real_volume
* soft_volume is always 0dB (ie. no soft volume)
If a filter sink doesn't follow the hardware sink volume, then the filter
sink's
* reference_volume can be whatever (completely independent from the hw sink)
* real_volume always equals reference_volume
* soft_volume always equals real_volume (and reference_volume)
If a filter sink follows the hardware sink volume, and the hardware sink
supports flat volume, then the filter sink's virtual stream's
* volume always equals the hw sink's real_volume
* reference_ratio is calculated normally from the stream volume and the hw
sink's reference_volume
* real_ratio always equals 0dB (follows from the first point)
* soft_volume always equals volume_factor (follows from the previous point)
If a filter sink follows the hardware sink volume, and the hardware sink
doesn't support flat volume, then the filter sink's virtual stream's
* volume is always 0dB
* reference_ratio is always 0dB
* real_ratio is always 0dB
* soft_volume always equals volume_factor
If a filter sink doesn't follow the hardware sink volume, then the filter
sink's virtual stream is handled as a regular stream.
Since the volumes of the virtual streams are controlled by a set of rules,
the user is not allowed to change the virtual streams' volumes. It would
probably also make sense to forbid changing the filter sinks' volume, but
that's not strictly necessary, and currently changing a filter sink's volume
changes actually the hardware sink's volume, and from there it propagates to
all filter sinks ("funny" effects are expected when adjusting a single
channel in cases where all sinks don't have the same channel maps).
This patch is based on the work of Marc-André Lureau, who did the
initial implementation for Pulseaudio 0.9.15.
There are two known cases where read-only or non-existing sink input volume is
relevant: passthrough streams and the planned volume sharing logic.
Passthrough streams don't have volume at all, and the volume sharing logic
requires read-only sink input volume. This commit is primarily working towards
the volume sharing feature, but support for non-existing sink input volume is
also added, because it is so closely related to read-only volume.
Some unrelated refactoring in iface-stream.c creeped into this commit too (new
function: stream_to_string()).
The check whether POSIX socket.h or WIN32 winsock2.h must be included can be
made centrally. The downside is that some functionality of e.g. arpa/inet.h is
also implemented in winsock.h, so that some files that don't use socket
functions, but do use inet.h functions, must also include pulsecore/socket.h.
(as well as arpa/inet.h)
Instead <pulsecore/poll.h> should be included. That file includes poll.h on
platform where it is appropriate. Also remove some unnecessary <ioctl.h>
includes.
