- Ensure there is enough disk space for the write file
- Switch streaming mode only if necessary
- Return `Err` on seeking errors, instead of exiting
- Use the actual position after seeking
This change fixes two issues with the error handling of the
Symphonia decode loop.
1) `Error::ResetRequired` should always be propagated to jump
to the next Spotify track.
2) On a decode error, get a new packet and try again instead of
propagating the error and jumping to the next track.
- Configure the decoder according to Spotify's metadata, don't probe
- Return from `AudioFile::open` as soon as possible, with the smallest
possible block size suitable for opening the decoder, so the UI
transitions from loading to playing/paused state. From there,
the regular prefetching will take over.
- Set ideal sample buffer size after decoding first full packet
- Prevent audio glitches after seeking
- Reset decoder when the format reader requires it
Credits: @pdeljanov
- 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.
- Don't load explicit tracks when the client setting forbids them
- When a client switches explicit filtering on *while* playing
an explicit track, immediately skip to the next track
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
Dynamically set the alsa buffer and period based on the device's reported min/max buffer and period sizes. In the event of failure use the device's defaults.
This should have no effect on devices that allow for reasonable buffer and period sizes but would allow us to be more forgiving with less reasonable devices or configurations.
Closes: https://github.com/librespot-org/librespot/issues/895
* Expose all fields of recent protobufs
* Add support for user-scoped playlists, user root playlists and
playlist annotations
* Convert messages with the Rust type system
* Attempt to adhere to embargos (tracks and episodes scheduled for
future release)
* Return `Result`s with meaningful errors instead of panicking on
`unwrap`s
* Add foundation for future playlist editing
* Up version in connection handshake to get all version-gated features
This makes `--device ?` only show compatible devices (ones that support 2 ch 44.1 Interleaved) and it shows what `librespot` format(s) they support.
This should be more useful to users as the info maps directly to `librespot`'s `--device` and `--format` options.
* Don't panic when parsing options. Instead list valid values and exit.
* Get rid of needless .expect in playback/src/audio_backend/mod.rs.
* Enforce reasonable ranges for option values (breaking).
* Don't evaluate options that would otherwise have no effect.
* Add pub const MIXERS to mixer/mod.rs very similar to the audio_backend's implementation. (non-breaking though)
* Use different option descriptions and error messages based on what backends are enabled at build time.
* Add a -q, --quiet option that changed the logging level to warn.
* Add a short name for every flag and option.
* Note removed options.
* Other misc cleanups.
While `Xoshiro256+` is faster on 64-bit, it has low linear complexity in the
lower three bits, which *are* used when generating dither.
Also, while `Xoshiro128StarStar` access one less variable from the heap,
multiplication is generally slower than addition in hardware.
* Make error messages more consistent and concise.
* `impl From<AlsaError> for io::Error` so `AlsaErrors` can be thrown to player as `io::Errors`. This little bit of boilerplate goes a long way to simplifying things further down in the code. And will make any needed future changes easier.
* Bonus: handle ALSA backend buffer sizing a little better.
* Improve error handling
* Harmonize `Seek`: Make the decoders and player use the same math for converting between samples and milliseconds
* Reduce duplicate calls: Make decoder seek in PCM, not ms
* Simplify decoder errors with `thiserror`
