| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
to save internal RAM space
|
|
This increases CPU usage by ~2% for the audio_conv task, which I
think is an acceptable tradeoff. The Speex resampler still
makes its own allocations in internal RAM.
|
|
The SetTrack event is sent when *decoding* finishes, not when
*playback* finishes so the decoder can start buffering the next
track in advance of its playback to ensure gapless playback.
Clearing StreamCues causes
Playback::react(const internal::StreamHeartbeat& ev)
to transit the Playback FSM to Standby, which sets the
IAudioOutput to stop reading from the output buffer. Thus,
clearing StreamCues in response to the SetTrack event paused
playback with the end of the track stuck waiting in the output
buffer. When a new queue was loaded and started playing, the
end of the previous track would be played before the new track
was played.
Fixes https://codeberg.org/cool-tech-zone/tangara-fw/issues/313
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Queue now has a separate 'ready' property to indicate it's ready to be used, which is independent from whether it's still loading tracks in. This also improves the response time for shuffling all tracks (we will initially pick a random track in the first 100 tracks whilst the rest of the tracks are loading). This should also fix issues where one song will start playing and then repeat itself when the queue finishes loading, and hopefully solve #160 as well (though I couldn't actually repro this myself).
Co-authored-by: jacqueline <me@jacqueline.id.au>
Reviewed-on: https://codeberg.org/cool-tech-zone/tangara-fw/pulls/170
Reviewed-by: cooljqln <cooljqln@noreply.codeberg.org>
Co-authored-by: ailurux <ailuruxx@gmail.com>
Co-committed-by: ailurux <ailuruxx@gmail.com>
|
|
|
|
|
|
I think this is what most folks would expect to happen if BT is
disconnected/disabled and the headphones are removed.
Also, I think(?) this fixes one situation where the device doesn't idle/
sleep when folks would expect it to (not connected to headphones or bt).
|
|
This replaces the previous system of a separate track and queue repeat, with a RepeatMode type with the following options and behaviours:
- OFF: No repeat, queue or track. When the current queue finishes, shuffled or otherwise, playback will stop.
- REPEAT_TRACK: The current track will loop indefinitely, unless next is explicitly called through some user action (ie using the next button in the now playing screen)
- REPEAT_QUEUE: The entire queue will repeat indefinitely. When shuffled is enabled this will repeat the queue with new combinations each cycle.
The repeat mode is persisted in non-volatile storage, so the behaviour will be consistent throughout restarts and queue replacements, and so the "queue repeat by default" use case can be met in this way.
In addition, I've made it work a little nicer when the queue runs out in the now playing screen, keeping the previously played track shown and playback can be continued by using the play button or by going to a previous song in the queue.
Reviewed-on: https://codeberg.org/cool-tech-zone/tangara-fw/pulls/126
Co-authored-by: ailurux <ailuruxx@gmail.com>
Co-committed-by: ailurux <ailuruxx@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Also fix a locking issue with opening+clearing
Co-authored-by: ailurux <ailuruxx@gmail.com>
|
|
|
|
|
|
|
|
|
|
Fixes #106
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- input files are upsamples and padded to stereo before playback
- any in-progress playback is cancelled before playing a new file
|
|
It's currently quite limited (no stereo or sample rate conversion,
multiple messages clobber each other, only plays if music is playing),
but we're getting there!
|
|
|
|
Includes a general cleanup+restructure of playlist.cpp, and fixing the
tests and benchmarks
|
|
Co-authored-by: jacqueline <me@jacqueline.id.au>
|
|
|
|
|
|
1) Update the queue length periodically so that the user can see we're
working
2) Clear any previous track and display "loading..." instead
|
|
|
