RGBCube/serenity
1
Fork 0
mirror of https://github.com/RGBCube/serenity synced 2025-07-27 14:07:45 +00:00
Code Issues Activity Actions

aplay: Preload more audio

Browse source 
This reduces glitching, but it is in no way a good solution. We should
really do the loading on another thread, but that's out of scope.
This commit is contained in:
kleines Filmröllchen 2022-11-23 14:34:14 +01:00 • committed by Andrew Kaster
parent 9b819a0dc9
commit c948777ec4
1 changed files with 1 additions and 5 deletions
Download patch file Download diff file Expand all files Collapse all files

6
Userland/Utilities/aplay.cpp
View file

@ -64,10 +64,6 @@ ErrorOr<int> serenity_main(Main::Arguments arguments)
// If we're downsampling, we need to appropriately load more samples at once. // If we're downsampling, we need to appropriately load more samples at once.
size_t const load_size = static_cast<size_t>(LOAD_CHUNK_SIZE * static_cast<double>(loader->sample_rate()) / static_cast<double>(audio_client->get_sample_rate())); size_t const load_size = static_cast<size_t>(LOAD_CHUNK_SIZE * static_cast<double>(loader->sample_rate()) / static_cast<double>(audio_client->get_sample_rate()));
// We assume that the loader can load samples at at least 2x speed (testing confirms 9x-12x for FLAC, 14x for WAV).
// Therefore, when the server-side buffer can only play as long as the time it takes us to load a chunk,
// we give it new data.
unsigned const min_buffer_size = load_size / 2;
auto print_playback_update = [&]() { auto print_playback_update = [&]() {
out("\033[u"); out("\033[u");
@ -115,7 +111,7 @@ ErrorOr<int> serenity_main(Main::Arguments arguments)
// We're done and the server is done // We're done and the server is done
break; break;
} }
while (audio_client->remaining_samples() > min_buffer_size) { while (audio_client->remaining_samples() > load_size) {
// The server has enough data for now // The server has enough data for now
print_playback_update(); print_playback_update();
usleep(1'000'000 / 10); usleep(1'000'000 / 10);