GitLab

Audio output plugins can use this to expedite discarding pending
buffers. This reduces latency upon seeking or stopping the input.

This new callback also supports explicit draining, but this is not
used for the time being.

This time, it should work (famous last words).

1kHz is way too much for human perception.

This unfortunately inserts silence shortly after resuming, right after
the samples that were held in the buffer during pause. This can possibly
be avoided with prebuffering (not tested).

VLC (like PulseAudio) stores the software volume i.e. the position of
the volume UI slider, rather than the linear amplification multiplier.

So do not use PulseAudio linear to volume conversion. Otherwise the
VLC volume gets wrongly cube-rooted.

This prepares for a possible cleanup of the audio output object,
especially hiding more stuff into the core.

Draining after flushing makes no sense. By the way, we should probably
wait for draining to complete. But there seems to be a race condition
in libpulse and this causes a deadlock.

This should fix buffer underflows in most cases.

Also move some stuff from vlc_config.h to vlc_aout*.h

Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

This is required for PulseAudio synchronization and to pause/resume
with low-latency. This should also be useful for other buffered
 audio outputs such as ALSA or CoreAudio.

This keeps the VLC value in sync with the PulseAudio one. For some
reason, the Qt4 interface does not pick up the correct default though.

Notes:

- The variable value represents the PulseAudio sink index.
  It is not a member of the AOUT_VAR_ enumeration.

- There is no configuration item. PulseAudio normally remembers the
  last sink VLC used. So I think there is no need value in writing
  code to duplicate that effort.

- I am not sure if we need more locking inside the variable callback.
  This needs to be clarified with PulseAudio guys.

This improves mute flag handling in the PulseAudio output:
We do not blindly reset the mute flag.

This enables use of PulseAudio flat volume, if enabled in PulseAudio.

Note that, in that case, VLC will multiply its own volume by the output
device ("sink" in PulseAudio parliance) base volume. That effectively
maps 100% volume in VLC to +0dB in PulseAudio. To me, that seems more
intuitive and backward compatible with older VLC versions.

However, PulseAudio people seem to think that 100% should be mapped to
the maximum hardware amplification without software amplification,
that is to say PA_VOLUME_NORM.

Known limitations:

* The initial volume is determined by PulseAudio. However VLC shows 100%
regardless, which is not necessarily correct.

* If the VLC stream/sink input volume is changed outside of VLC (by a
mixer application), the VLC user interface will not see the updated
value.