Only two call sites checked for errors. Anyway, the implementation does
not check for errors.

Only software amplification is left

When asked for more than one reference to an audio output instance, the
input resource will now return distinct instances, instead of multiple
references to a unique instance. This means each audio decoder will use
an audio output of its own. Earlier, audio decoders from the same input
would share their output through a mixer.

In practice, this change does not make much difference. Indeed, there
is normally only one active AUDIO_ES decoder_t/aout_input_t per input
in any case. There is one quirk to render multiple audio tracks:
 # vlc --sout-all --sout '#display'

There are a few advantages to this approach:

- The output of each audio track can be controlled independently. For
instance, different tracks can be routed to different devices,
different ports, or in theory at least, to different output plugins.

- This enables simplification of the audio output subsystem as it can
now be assumed that there is only one (or zero) input per output.
Track mixing is not required anymore. This is not to be confused with
channel mixing!

- We can get rid of the audio mixer plugins completely.

There are also disadvantages. But there was no way to run into this
situation with VLC, except for the --sout-all quirk as far as I know:

- If the output does not support mixing internally, only one track can
be rendered at a time. But any sane operating system supports mixing in
hardware or software, so that more than one process can output audio.

- The audio tracks might not be in perfect synchronization anymore.

Note that the user interface does not support more than one output any
better than the input (ES output) core. The input resource currently
only keeps track of one audio output, but this could be fixed if
needed. If you use PulseAudio, you can control the extrar outputs using
an external PulseAudio mixer UI; I don't know about other systems.

Effectively, the aout instance reference within the decoder now has the
same lifetime has the aout input. As the aout instance is kept in the
input resource, this does not really make any functional difference.

The input resource creates the aout instance with the input manager as
its parent object.

If this fail, the aout input should not be created at all. This removes
the fallback to an aout instance with the decoder object as parent.
This would potentially crash as the decoder is shorter-lived than the
aout instance.

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.

No functional changes. Some more can't be replaced yet, as we still support 10.5

300 743 v1.2.1 mentionned '1111 1111', but 1.3.1 mentions '11 1111' only.
I believe it is a typo, (maybe, maybe not) but the spec is out, so people
will write encoders following it.
So, we do not look at the 2 bits of strong weight.

Thanks for the hint.

there may be to be investigated problems with non-ASCII keys

This provides more stable names especially for hot-plugged devices,
and more evocative descriptions for the user. As an added bonus, the
code is more compact.

Note however that this is not thread-safe. This is a common problem for
configuration items with update callbacks.

Signed-off-by: Laurent Aimar <fenrir@videolan.org>

This should fix practically glitches. The resulting A/V synchronization
is not too bad for me inspite of the long buffer (1/2 seconds).
Your mileage may vary.

Signed-off-by: Rémi Duraffort <ivoire@videolan.org>

Implementation of fork() is imperfect on OS/2.

Pointed-out-by: KO Myung-Hun