Previously, SoundPlayer would read and enqueue samples in the GUI loop
(through a Timer). Apart from general problems with doing audio on the
GUI thread, this is particularly bad as the audio would lag or drop out
when the GUI lags (e.g. window resizes and moves, changing the
visualizer). As Piano does, now SoundPlayer enqueues more audio once the
audio server signals that a buffer has finished playing. The GUI-
dependent decoding is still kept as a "backup" and to start the entire
cycle, but it's not solely depended on. A queue of buffer IDs is used to
keep track of playing buffers and how many there are. The buffer
overhead, i.e. how many buffers "too many" currently exist, is currently
set to its absolute minimum of 2.
This is a first pass at refactoring SoundPlayer so that the View widget
is decoupled from the player itself.
In doing so, this fixed a couple of issues, including possibly
inconsistent states (e.g. player could be paused and stopped at the
same time).
With the change, Player actually controls the show, and calls methods
overriden by its subclasses to perform actions, such as update the Seek
bar; the hard work of massaging the raw data is done by the Player
class, so subclasses don't need to reimplement any of these things.
This also removes some copies of playlist management code that happened
to be copied+pasted inside callbacks of buttons -- it now lives inside
a neatly packaged Playlist class, and the Player only asks for the next
song to play.
In addition, the menu bar has been slightly rearranged.
All audio applications (aplay, Piano, Sound Player) respect the ability
of the system to have theoretically any sample rate. Therefore, they
resample their own audio into the system sample rate.
LibAudio previously had its loaders resample their own audio, even
though they expose their sample rate. This is now changed. The loaders
output audio data in their file's sample rate, which the user has to
query and resample appropriately. Resampling code from Buffer, WavLoader
and FlacLoader is removed.
Note that these applications only check the sample rate at startup,
which is reasonable (the user has to restart applications when changing
the sample rate). Fully dynamic adaptation could both lead to errors and
will require another IPC interface. This seems to be enough for now.
This commit addresses two issues:
1. If you play a 96 KHz Wave file, the slider position is incorrect,
because it is assumed all files are 44.1 KHz.
2. For high-bitrate files, there are audio dropouts due to not
buffering enough audio data.
Issue 1 is addressed by scaling the number of played samples by the
ratio between the source and destination sample rates.
Issue 2 is addressed by buffering a certain number of milliseconds
worth of audio data (instead of a fixed number of bytes).
This makes the the buffer size independent of the source sample rate.
Some of the code is redesigned to be simpler. The code that did the
book-keeping of which buffers need to be loaded and which have been
already played has been removed. Instead, we enqueue a new buffer based
on a low watermark of samples remaining in the audio server queue.
Other small fixes include:
1. Disable the stop button when playback is finished.
2. Remove hard-coded instances of 44100.
3. Update the GUI every 50 ms (was 100), which improves visualizations.
SPDX License Identifiers are a more compact / standardized
way of representing file license information.
See: https://spdx.dev/resources/use/#identifiers
This was done with the `ambr` search and replace tool.
ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
