- Switch from `lewton` to `Symphonia`. This is a pure Rust demuxer
and decoder in active development that supports a wide range of
formats, including Ogg Vorbis, MP3, AAC and FLAC for future HiFi
support. At the moment only Ogg Vorbis and MP3 are enabled; all
AAC files are DRM-protected.
- Bump MSRV to 1.51, required for `Symphonia`.
- Filter out all files whose format is not specified.
- Not all episodes seem to be encrypted. If we can't get an audio
key, try and see if we can play the file without decryption.
- After seeking, report the actual position instead of the target.
- Remove the 0xa7 bytes offset from `Subfile`, `Symphonia` does
not balk at Spotify's custom Ogg packet before it. This also
simplifies handling of formats other than Ogg Vorbis.
- When there is no next track to load, signal the UI that the
player has stopped. Before, the player would get stuck in an
infinite reloading loop when there was only one track in the
queue and that track could not be loaded.
This should fix remaining cases of a client connecting, and failing
to start playback from *beyond* the beginning when `librespot` is
still loading that track.
This undoes the `suppress_loading_status` workaround from #430,
under the assumption that the race condition reported there has
since been fixed on Spotify's end.
Further changes:
- Improve some debug and trace messages
- Default to streaming download strategy
- Synchronize mixer volume on loading play
- Use default normalisation values when the file position isn't
exactly what we need it to be
- Update track position only when the decoder reports a
successful seek
* Remove deprecated use of std::u16::MAX
* Use `FromStr` for fallible `&str` conversions
* DRY up strings into constants
* Change `as_ref().map()` into `as_deref()`
* Use `Duration` for time constants and functions
* Optimize `Vec` with response times
* Move comments for `rustdoc` to parse
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`.
