| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Only whitespace changes in here
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is needed to better support out of tree builds (including
distcheck) and to ensure the necessary folders are created in the
build tree on configure and also works around an intl-tools bug
(https://bugs.launchpad.net/intltool/+bug/605826)
The Makefile.am's used are minimal (and in some cases completely
blank). At present they do not include anything interesting
with the majority of the real work still done by the monolitic
src/Makefile.am
It may make sense to start splitting out src/Makefile.am into
smaller chunks but this commit makes the minimum changes to address
the issues that result from using make distcheck and other out of
tree builds.
Note: This 'breaks' the ability to type make in e.g. the src/modules
folder and have all of PA rebuilt accordingly (this is because the
static Makefiles previously present just did a "make -C ..") which
was purportedly for use in emacs. But I'm sure there will be a better
and more robust way to configure emacs to do your builds properly if
this behaviour is still desirable.
|
|
|
|
|
|
| |
This ensures that we always clamp the volume to PA_VOLUME_MAX. While
this currently has no effect, it will be required for making sure we
don't exceed PA_VOLUME_MAX when its value changes in the future.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- We now implement a logic where the sink maintains two distinct
volumes: the 'reference' volume which is shown to the users, and the
'real' volume, which is configured to the hardware. The latter is
configured to the max of all streams. Volume changes on sinks are
propagated back to the streams proportional to the reference volume
change. Volume changes on sink inputs are forwarded to the sink by
'pushing' the volume if necessary.
This renames the old 'virtual_volume' to 'real_volume'. The
'reference_volume' is now the one exposed to users.
By this logic the sink volume visible to the user, will always be the
"upper" boundary for everything that is played. Saved/restored stream
volumes are measured relative to this boundary, the factor here is
always < 1.0.
- introduce accuracy for sink volumes, similar to the accuracy we
already have for source volumes.
- other cleanups.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- drop the 'virtual_' prefix from s->virtual_volume since we don't
distuingish between reference and real volumes for sources
- introduce an accuracy for source volumes: if the hardware can control
the volume "close enough" don't necessarily adjust the rest in
software unless it is beyond a certain threshold. This should save a
little bit of CPU at the expensive of a bit of accuracy in volume
handling.
- other minor cleanups
|
|
|
|
| |
finally fixed for granularity
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This allows us to forward the fixed latency directly from the sink to
the monitor source withut having to wait for pa_sink_put().
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The reference volume is to be used as reference volume for stored stream
volumes. Previously if a new stream was created the relative volume was
taken relatively to the virtual device volume. Due to the flat volume
logic this could then be fed back to the virtual device volume.
Repeating the whole story over and over would result in a device volume
that would go lower, and lower and lower.
This patch introduces a 'reference' volume for each sink which stays
unmodified by stream volume changes even if flat volumes are used. It is
only modified if the sink volumes are modified directly by the user.
For further explanations see http://pulseaudio.org/wiki/InternalVolumes
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
field to sinks/sources
|
|
|
|
| |
Signed-off-by: Lennart Poettering <lennart@poettering.net>
|
|
|
|
| |
Signed-off-by: Lennart Poettering <lennart@poettering.net>
|
|
|
|
|
|
|
|
|
|
|
| |
did the first time
In OSS it is only possible to request fragment sizes that are powers of
2. However actually selected fragment sizes may be arbitrary values.
This means that it is not always possible to request the same fragment
size after a suspend that was used before the suspend because we simply
cannot express it in the request. To work around that we should issue
the same request as we did the first time.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|