Some of the feature flags librespot uses are not really additive but
rather mutual exclusive. A previous attempt to improve the situation
had other drawbacks, so it's better to postpone a decision and restore
the old behaviour.
- DRY-ups
- Remove incorrect optimization attempt in the libvorbis decoder,
that skewed 0.0 samples non-linear
- PortAudio and SDL backends do not support S24 output. The PortAudio
bindings could, but not through this API.
Usage: `--format {F32|S16}`. Default is F32.
- Implemented for all backends, except for JACK audio which itself
only supports 32-bit output at this time. Setting JACK audio to S16
will panic and instruct the user to set output to F32.
- The F32 default works fine for Rodio on macOS, but not on Raspian 10
with Alsa as host. Therefore users on Linux systems are warned to set
output to S16 in case of garbled sound with Rodio. This seems an issue
with cpal incorrectly detecting the output stream format.
- While at it, DRY up lots of code in the backends and by that virtue,
also enable OggData passthrough on the subprocess backend.
- I tested Rodio, ALSA, pipe and subprocess quite a bit, and call on
others to join in and test the other backends.
- Store and output samples as 32-bit floats instead of 16-bit integers.
This provides 24-25 bits of transparency, allowing for 42-48 dB of
headroom to do volume control and normalisation without throwing
away bits or dropping dynamic range below 96 dB CD quality.
- Perform volume control and normalisation in 64-bit arithmetic.
- Add a dynamic limiter with configurable threshold, attack time,
release or decay time, and steepness for the sigmoid transfer
function. This mimics the native Spotify limiter, offering greater
dynamic range than the old limiter, that just reduced overall gain
to prevent clipping.
- Make the configurable threshold also apply to the old limiter, which
is still available.
Resolves: librespot-org/librespot#608
Previously, polling `AudioFileFetch` consisted of three parts: Handling
stream loader commands, handling received data, and triggering preloading
in stream mode when the number of open requests is sufficiently small. The
first steps use channels which are polled, and if something's available,
it's handled. The third step is executed on every call of `poll`.
The first two could easily be refactored using a `tokio::select!`-loop.
Therefore, counting the number of open requests was also refactored to fit
into this scheme. They were previously counted using a shared
`AtomicUsize`. Now, the number of open requests is stored exclusively in
`AudioFileFetch`, increased on starting a request, and decreased by an
oneshot channel that is fired when a request is finished.
This allows us to `select` that channel in the loop too, and since
loading ahead makes only sense if the number of open requests decreases,
the third step is only executed in this case.
`AudioFileFetch` does not implement `Future` anymore, but is rather used
as helper struct in an async fn `audio_file_fetch`.
