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).
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.
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.
The assertion message is misleading, since the passthrough connection
can fail for reasons the client has no control over (like other sink
inputs being connected).
Since we currently have two mechanisms to signal a passthrough
connection (non-PCM format or PA_SINK_INPUT_PASSTHROUGH flag), we move
all the related checks into functions and use those everywhere.
This makes things more consistent, and should we decide to get rid of
the flag, we only need to change pa_sink_input_*_is_passthrough()
accordingly.
In most cases it is expected that clients cannot consume compressed
data from monitor sources, so we suspend the monitor source when the
sink goes into passthrough mode.
Eventually, when the extended API includes client notifications for
changed formats, we should emit a notification on the monitor so that
clients can decide what they want to do when this happens (disconnect or
consume the data anyway).
This will eventually be replaced by a hook to let clients know that the
stream has moved so that they can gracefully reconnect and renegotiate a
supported format.
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 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.
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()).
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.
Second version after Tanu's feedback
TODO:
- notify client that volume control is disabled
- change sink rate in passthrough mode if needed
- automatic detection of passthrough mode instead of hard
coded profile names
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@intel.com>
All seeks/flushes that depend on the playback buffer read pointer cannot
be accounted for properly in the client since it does not know the
actual read pointer. Due to that the clients do not account for it at
all. We need do the same on the server side. And we did, but a little
bit too extreme. While we properly have not applied the changes to the
"request" counter we still do have to apply it to the "missing" counter.
This patch fixes that.
Hi,
I found that volume ramping is inside PA now.
there's a minor fix here, it is a bug i found after the patch is submitted:
line 1781 of sink-input.c :
if ((i->thread_info.ramp_info.envelope_dying - nbytes) <= 0) {
need to be changed to
if ((i->thread_info.ramp_info.envelope_dying - (ssize_t) nbytes) <= 0) {
otherwise this argument will never be negative since nbytes is of type
size_t which is unsigned.
Please change it when you have time, sorry if bring any inconvenience. :)
