This is not set by pax11publish, but module-x11-publish does so this tool
should tidy that up. It is only removed when passing -r and is
ignored when actually setting up it's own properties from the conf
files/guesswork.
This reverts commit 95a98fe6f2.
Conflicts:
src/Makefile.am
src/pulsecore/envelope.c
src/pulsecore/envelope.h
src/tests/envelope-test.c
(part of a patch series removing all ramping code)
If the virtual sink is moved to a new master right after it has been created,
then the virtual sink input's memblockq can be rewound to a negative read
index. The data written prior to the move starts from index zero, so after the
rewind there's a bit of silence. If the memblockq doesn't have a silence
memchunk set, then pa_memblockq_peek() will return zero in such case, and the
returned memchunk's memblock pointer will be NULL.
That scenario wasn't taken into account in the implementation of
sink_input_pop_cb. Setting a silence memchunk for the memblockq solves this
problem, because pa_memblock_peek() will now return a valid memblock if the
read index happens to point to a hole in the memblockq.
I believe this isn't the best possible solution, though. It doesn't really make
sense to rewind the sink input's memblockq beyond index 0 in the first place,
because now when the stream starts to play to the new master sink, there's some
unnecessary silence before the actual data starts. This is a small problem,
though, and I don't grok the rewinding system well enough to know how to fix
this issue properly.
I went through all files that call pa_memblockq_peek() to see if there are more
similar bugs. play-memblockq.c was the only one that looked to me like it might
be broken in the same way. I didn't try reproducing the bug with
play-memblockq.c, though, so I just added a FIXME comment there.
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.
Make sure that mic and line (with common names) use the specific
path instead of the analog-input one.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Now you can add required-any to elements in a path and the path
will be valid as long as at least one of the elements are present.
Also you can have required, required-any and required-absent in
element options, causing a path to be unsupported if an option is
(not) present (simplified example: to skip line in path if
"Capture source" doesn't have a "Line In" option).
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Add front mic, rear mic, and docking line-in. These are likely to be
present on modern hda chips, for reference see
linux-2.6/sound/pci/hda/hda_codec.c:hda_get_input_pin_label
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
When creating synthesized paths, pa_alsa_path_set_new() created duplicate
elements for each path, and one of the duplicate elements would be marked as
required absent. That made path probing fail. While debugging this, I noticed
also that pa_alsa_path_synthesize() didn't initialize p->last_element properly.
This will allow modules to know when a card profile has changed
and take appropriate action. This might prove useful when developing
UCM so that the appropriate verb can be set.
This allows modules to know when certain ports are changed.
This will allow e.g. a filter module (or LADSAP) to only load
when a certain port is used on the device (e.g. to only filter
headphones and not normal speakers).
(Comment from Colin Guthrie: This may also have use in UCM)
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.
Using uClibc
AM_LIBADD = $(PTHREAD_LIBS) $(INTLLIBS)
is not empty because `$(INTLLIBS)` is set to `-lintl`. This uncovered a missing space in commit ef0cc745 which resulted in the following build error.
[…]
CC libbluetooth_ipc_la-ipc.lo
modules/bluetooth/ipc.c: In function 'bt_audio_service_open':
modules/bluetooth/ipc.c:65:26: warning: dereferencing type-punned pointer might break strict-aliasing rules [-Wstrict-aliasing]
modules/bluetooth/ipc.c: In function 'bt_audio_service_get_data_fd':
modules/bluetooth/ipc.c:110:13: warning: cast increases required alignment of target type [-Wcast-align]
modules/bluetooth/ipc.c:110:4: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
make[3]: *** No rule to make target `-lintl', needed by `libbluetooth-ipc.la'. Stop.
make[3]: Leaving directory `/oe/build-minimal-uclibc/minimal-uclibc-dev/work/armv7a-oe-linux-uclibceabi/pulseaudio-0.9.22-r11.0+gitr0+051d82133f0ae6a57bf66fd200bc8e3591a7d5ca/git/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/oe/build-minimal-uclibc/minimal-uclibc-dev/work/armv7a-oe-linux-uclibceabi/pulseaudio-0.9.22-r11.0+gitr0+051d82133f0ae6a57bf66fd200bc8e3591a7d5ca/git/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/oe/build-minimal-uclibc/minimal-uclibc-dev/work/armv7a-oe-linux-uclibceabi/pulseaudio-0.9.22-r11.0+gitr0+051d82133f0ae6a57bf66fd200bc8e3591a7d5ca/git'
make: *** [all] Error 2
This patch is taken from OpenEmbedded where it has been present since 2009 for PulseAudio 0.9.15 and greater [1].
[1] http://git.0pointer.de/?p=pulseaudio.git;a=commit;h=ef0cc74567b3bb98378c17f6a523bf18ba132ed7
[2] http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=7c33f2e906a20e139d53b4f2d8fbc2773a4725b3
Signed-off-by: Henning Heinold <heinold@inf.fu-berlin.de>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
CC: Henning Heinold <heinold@inf.fu-berlin.de>
