ladybird/Userland/Libraries/LibAudio/Loader.cpp

120 lines
4 KiB
C++
Raw Normal View History

/*
* Copyright (c) 2018-2023, the SerenityOS developers.
*
* SPDX-License-Identifier: BSD-2-Clause
*/
LibAudio: Move audio stream buffering into the loader Before, some loader plugins implemented their own buffering (FLAC&MP3), some didn't require any (WAV), and some didn't buffer at all (QOA). This meant that in practice, while you could load arbitrary amounts of samples from some loader plugins, you couldn't do that with some others. Also, it was ill-defined how many samples you would actually get back from a get_more_samples call. This commit fixes that by introducing a layer of abstraction between the loader and its plugins (because that's the whole point of having the extra class!). The plugins now only implement a load_chunks() function, which is much simpler to implement and allows plugins to play fast and loose with what they actually return. Basically, they can return many chunks of samples, where one chunk is simply a convenient block of samples to load. In fact, some loaders such as FLAC and QOA have separate internal functions for loading exactly one chunk. The loaders *should* load as many chunks as necessary for the sample count to be reached or surpassed (the latter simplifies loading loops in the implementations, since you don't need to know how large your next chunk is going to be; a problem for e.g. FLAC). If a plugin has no problems returning data of arbitrary size (currently WAV), it can return a single chunk that exactly (or roughly) matches the requested sample count. If a plugin is at the stream end, it can also return less samples than was requested! The loader can handle all of these cases and may call into load_chunk multiple times. If the plugin returns an empty chunk list (or only empty chunks; again, they can play fast and loose), the loader takes that as a stream end signal. Otherwise, the loader will always return exactly as many samples as the user requested. Buffering is handled by the loader, allowing any underlying plugin to deal with any weird sample count requirement the user throws at it (looking at you, SoundPlayer!). This (not accidentally!) makes QOA work in SoundPlayer.
2023-02-27 00:05:14 +01:00
#include <AK/TypedTransfer.h>
#include <LibAudio/FlacLoader.h>
2021-11-27 17:00:19 +01:00
#include <LibAudio/Loader.h>
#include <LibAudio/MP3Loader.h>
#include <LibAudio/QOALoader.h>
#include <LibAudio/WavLoader.h>
#include <LibCore/File.h>
namespace Audio {
LoaderPlugin::LoaderPlugin(NonnullOwnPtr<SeekableStream> stream)
: m_stream(move(stream))
{
}
2021-11-27 17:00:19 +01:00
Loader::Loader(NonnullOwnPtr<LoaderPlugin> plugin)
: m_plugin(move(plugin))
{
}
struct LoaderPluginInitializer {
bool (*sniff)(SeekableStream&);
ErrorOr<NonnullOwnPtr<LoaderPlugin>, LoaderError> (*create)(NonnullOwnPtr<SeekableStream>);
};
#define ENUMERATE_LOADER_PLUGINS \
__ENUMERATE_LOADER_PLUGIN(Wav) \
__ENUMERATE_LOADER_PLUGIN(Flac) \
__ENUMERATE_LOADER_PLUGIN(QOA) \
__ENUMERATE_LOADER_PLUGIN(MP3)
static constexpr LoaderPluginInitializer s_initializers[] = {
#define __ENUMERATE_LOADER_PLUGIN(Type) \
{ Type##LoaderPlugin::sniff, Type##LoaderPlugin::create },
ENUMERATE_LOADER_PLUGINS
#undef __ENUMERATE_LOADER_PLUGIN
};
ErrorOr<NonnullRefPtr<Loader>, LoaderError> Loader::create(StringView path)
{
auto stream = TRY(Core::InputBufferedFile::create(TRY(Core::File::open(path, Core::File::OpenMode::Read))));
return adopt_ref(*new (nothrow) Loader(TRY(Loader::create_plugin(move(stream)))));
2021-11-27 17:00:19 +01:00
}
ErrorOr<NonnullRefPtr<Loader>, LoaderError> Loader::create(Bytes buffer)
2021-11-27 17:00:19 +01:00
{
auto stream = TRY(try_make<FixedMemoryStream>(buffer));
return adopt_ref(*new (nothrow) Loader(TRY(Loader::create_plugin(move(stream)))));
}
ErrorOr<NonnullOwnPtr<LoaderPlugin>, LoaderError> Loader::create_plugin(NonnullOwnPtr<SeekableStream> stream)
{
for (auto const& loader : s_initializers) {
if (loader.sniff(*stream)) {
TRY(stream->seek(0, SeekMode::SetPosition));
return loader.create(move(stream));
}
TRY(stream->seek(0, SeekMode::SetPosition));
}
2021-11-27 17:00:19 +01:00
return LoaderError { "No loader plugin available" };
}
LibAudio: Move audio stream buffering into the loader Before, some loader plugins implemented their own buffering (FLAC&MP3), some didn't require any (WAV), and some didn't buffer at all (QOA). This meant that in practice, while you could load arbitrary amounts of samples from some loader plugins, you couldn't do that with some others. Also, it was ill-defined how many samples you would actually get back from a get_more_samples call. This commit fixes that by introducing a layer of abstraction between the loader and its plugins (because that's the whole point of having the extra class!). The plugins now only implement a load_chunks() function, which is much simpler to implement and allows plugins to play fast and loose with what they actually return. Basically, they can return many chunks of samples, where one chunk is simply a convenient block of samples to load. In fact, some loaders such as FLAC and QOA have separate internal functions for loading exactly one chunk. The loaders *should* load as many chunks as necessary for the sample count to be reached or surpassed (the latter simplifies loading loops in the implementations, since you don't need to know how large your next chunk is going to be; a problem for e.g. FLAC). If a plugin has no problems returning data of arbitrary size (currently WAV), it can return a single chunk that exactly (or roughly) matches the requested sample count. If a plugin is at the stream end, it can also return less samples than was requested! The loader can handle all of these cases and may call into load_chunk multiple times. If the plugin returns an empty chunk list (or only empty chunks; again, they can play fast and loose), the loader takes that as a stream end signal. Otherwise, the loader will always return exactly as many samples as the user requested. Buffering is handled by the loader, allowing any underlying plugin to deal with any weird sample count requirement the user throws at it (looking at you, SoundPlayer!). This (not accidentally!) makes QOA work in SoundPlayer.
2023-02-27 00:05:14 +01:00
LoaderSamples Loader::get_more_samples(size_t samples_to_read_from_input)
{
if (m_plugin_at_end_of_stream)
return FixedArray<Sample> {};
LibAudio: Move audio stream buffering into the loader Before, some loader plugins implemented their own buffering (FLAC&MP3), some didn't require any (WAV), and some didn't buffer at all (QOA). This meant that in practice, while you could load arbitrary amounts of samples from some loader plugins, you couldn't do that with some others. Also, it was ill-defined how many samples you would actually get back from a get_more_samples call. This commit fixes that by introducing a layer of abstraction between the loader and its plugins (because that's the whole point of having the extra class!). The plugins now only implement a load_chunks() function, which is much simpler to implement and allows plugins to play fast and loose with what they actually return. Basically, they can return many chunks of samples, where one chunk is simply a convenient block of samples to load. In fact, some loaders such as FLAC and QOA have separate internal functions for loading exactly one chunk. The loaders *should* load as many chunks as necessary for the sample count to be reached or surpassed (the latter simplifies loading loops in the implementations, since you don't need to know how large your next chunk is going to be; a problem for e.g. FLAC). If a plugin has no problems returning data of arbitrary size (currently WAV), it can return a single chunk that exactly (or roughly) matches the requested sample count. If a plugin is at the stream end, it can also return less samples than was requested! The loader can handle all of these cases and may call into load_chunk multiple times. If the plugin returns an empty chunk list (or only empty chunks; again, they can play fast and loose), the loader takes that as a stream end signal. Otherwise, the loader will always return exactly as many samples as the user requested. Buffering is handled by the loader, allowing any underlying plugin to deal with any weird sample count requirement the user throws at it (looking at you, SoundPlayer!). This (not accidentally!) makes QOA work in SoundPlayer.
2023-02-27 00:05:14 +01:00
size_t remaining_samples = total_samples() - loaded_samples();
size_t samples_to_read = min(remaining_samples, samples_to_read_from_input);
auto samples = TRY(FixedArray<Sample>::create(samples_to_read));
LibAudio: Move audio stream buffering into the loader Before, some loader plugins implemented their own buffering (FLAC&MP3), some didn't require any (WAV), and some didn't buffer at all (QOA). This meant that in practice, while you could load arbitrary amounts of samples from some loader plugins, you couldn't do that with some others. Also, it was ill-defined how many samples you would actually get back from a get_more_samples call. This commit fixes that by introducing a layer of abstraction between the loader and its plugins (because that's the whole point of having the extra class!). The plugins now only implement a load_chunks() function, which is much simpler to implement and allows plugins to play fast and loose with what they actually return. Basically, they can return many chunks of samples, where one chunk is simply a convenient block of samples to load. In fact, some loaders such as FLAC and QOA have separate internal functions for loading exactly one chunk. The loaders *should* load as many chunks as necessary for the sample count to be reached or surpassed (the latter simplifies loading loops in the implementations, since you don't need to know how large your next chunk is going to be; a problem for e.g. FLAC). If a plugin has no problems returning data of arbitrary size (currently WAV), it can return a single chunk that exactly (or roughly) matches the requested sample count. If a plugin is at the stream end, it can also return less samples than was requested! The loader can handle all of these cases and may call into load_chunk multiple times. If the plugin returns an empty chunk list (or only empty chunks; again, they can play fast and loose), the loader takes that as a stream end signal. Otherwise, the loader will always return exactly as many samples as the user requested. Buffering is handled by the loader, allowing any underlying plugin to deal with any weird sample count requirement the user throws at it (looking at you, SoundPlayer!). This (not accidentally!) makes QOA work in SoundPlayer.
2023-02-27 00:05:14 +01:00
size_t sample_index = 0;
if (m_buffer.size() > 0) {
size_t to_transfer = min(m_buffer.size(), samples_to_read);
AK::TypedTransfer<Sample>::move(samples.data(), m_buffer.data(), to_transfer);
if (to_transfer < m_buffer.size())
m_buffer.remove(0, to_transfer);
else
m_buffer.clear_with_capacity();
sample_index += to_transfer;
}
while (sample_index < samples_to_read) {
auto chunk_data = TRY(m_plugin->load_chunks(samples_to_read - sample_index));
chunk_data.remove_all_matching([](auto& chunk) { return chunk.is_empty(); });
if (chunk_data.is_empty()) {
m_plugin_at_end_of_stream = true;
LibAudio: Move audio stream buffering into the loader Before, some loader plugins implemented their own buffering (FLAC&MP3), some didn't require any (WAV), and some didn't buffer at all (QOA). This meant that in practice, while you could load arbitrary amounts of samples from some loader plugins, you couldn't do that with some others. Also, it was ill-defined how many samples you would actually get back from a get_more_samples call. This commit fixes that by introducing a layer of abstraction between the loader and its plugins (because that's the whole point of having the extra class!). The plugins now only implement a load_chunks() function, which is much simpler to implement and allows plugins to play fast and loose with what they actually return. Basically, they can return many chunks of samples, where one chunk is simply a convenient block of samples to load. In fact, some loaders such as FLAC and QOA have separate internal functions for loading exactly one chunk. The loaders *should* load as many chunks as necessary for the sample count to be reached or surpassed (the latter simplifies loading loops in the implementations, since you don't need to know how large your next chunk is going to be; a problem for e.g. FLAC). If a plugin has no problems returning data of arbitrary size (currently WAV), it can return a single chunk that exactly (or roughly) matches the requested sample count. If a plugin is at the stream end, it can also return less samples than was requested! The loader can handle all of these cases and may call into load_chunk multiple times. If the plugin returns an empty chunk list (or only empty chunks; again, they can play fast and loose), the loader takes that as a stream end signal. Otherwise, the loader will always return exactly as many samples as the user requested. Buffering is handled by the loader, allowing any underlying plugin to deal with any weird sample count requirement the user throws at it (looking at you, SoundPlayer!). This (not accidentally!) makes QOA work in SoundPlayer.
2023-02-27 00:05:14 +01:00
break;
}
LibAudio: Move audio stream buffering into the loader Before, some loader plugins implemented their own buffering (FLAC&MP3), some didn't require any (WAV), and some didn't buffer at all (QOA). This meant that in practice, while you could load arbitrary amounts of samples from some loader plugins, you couldn't do that with some others. Also, it was ill-defined how many samples you would actually get back from a get_more_samples call. This commit fixes that by introducing a layer of abstraction between the loader and its plugins (because that's the whole point of having the extra class!). The plugins now only implement a load_chunks() function, which is much simpler to implement and allows plugins to play fast and loose with what they actually return. Basically, they can return many chunks of samples, where one chunk is simply a convenient block of samples to load. In fact, some loaders such as FLAC and QOA have separate internal functions for loading exactly one chunk. The loaders *should* load as many chunks as necessary for the sample count to be reached or surpassed (the latter simplifies loading loops in the implementations, since you don't need to know how large your next chunk is going to be; a problem for e.g. FLAC). If a plugin has no problems returning data of arbitrary size (currently WAV), it can return a single chunk that exactly (or roughly) matches the requested sample count. If a plugin is at the stream end, it can also return less samples than was requested! The loader can handle all of these cases and may call into load_chunk multiple times. If the plugin returns an empty chunk list (or only empty chunks; again, they can play fast and loose), the loader takes that as a stream end signal. Otherwise, the loader will always return exactly as many samples as the user requested. Buffering is handled by the loader, allowing any underlying plugin to deal with any weird sample count requirement the user throws at it (looking at you, SoundPlayer!). This (not accidentally!) makes QOA work in SoundPlayer.
2023-02-27 00:05:14 +01:00
for (auto& chunk : chunk_data) {
if (sample_index < samples_to_read) {
auto count = min(samples_to_read - sample_index, chunk.size());
AK::TypedTransfer<Sample>::move(samples.span().offset(sample_index), chunk.data(), count);
// We didn't read all of the chunk; transfer the rest into the buffer.
if (count < chunk.size()) {
auto remaining_samples_count = chunk.size() - count;
// We will always have an empty buffer at this point!
TRY(m_buffer.try_append(chunk.span().offset(count), remaining_samples_count));
LibAudio: Move audio stream buffering into the loader Before, some loader plugins implemented their own buffering (FLAC&MP3), some didn't require any (WAV), and some didn't buffer at all (QOA). This meant that in practice, while you could load arbitrary amounts of samples from some loader plugins, you couldn't do that with some others. Also, it was ill-defined how many samples you would actually get back from a get_more_samples call. This commit fixes that by introducing a layer of abstraction between the loader and its plugins (because that's the whole point of having the extra class!). The plugins now only implement a load_chunks() function, which is much simpler to implement and allows plugins to play fast and loose with what they actually return. Basically, they can return many chunks of samples, where one chunk is simply a convenient block of samples to load. In fact, some loaders such as FLAC and QOA have separate internal functions for loading exactly one chunk. The loaders *should* load as many chunks as necessary for the sample count to be reached or surpassed (the latter simplifies loading loops in the implementations, since you don't need to know how large your next chunk is going to be; a problem for e.g. FLAC). If a plugin has no problems returning data of arbitrary size (currently WAV), it can return a single chunk that exactly (or roughly) matches the requested sample count. If a plugin is at the stream end, it can also return less samples than was requested! The loader can handle all of these cases and may call into load_chunk multiple times. If the plugin returns an empty chunk list (or only empty chunks; again, they can play fast and loose), the loader takes that as a stream end signal. Otherwise, the loader will always return exactly as many samples as the user requested. Buffering is handled by the loader, allowing any underlying plugin to deal with any weird sample count requirement the user throws at it (looking at you, SoundPlayer!). This (not accidentally!) makes QOA work in SoundPlayer.
2023-02-27 00:05:14 +01:00
}
} else {
// We're now past what the user requested. Transfer the entirety of the data into the buffer.
TRY(m_buffer.try_append(chunk.data(), chunk.size()));
LibAudio: Move audio stream buffering into the loader Before, some loader plugins implemented their own buffering (FLAC&MP3), some didn't require any (WAV), and some didn't buffer at all (QOA). This meant that in practice, while you could load arbitrary amounts of samples from some loader plugins, you couldn't do that with some others. Also, it was ill-defined how many samples you would actually get back from a get_more_samples call. This commit fixes that by introducing a layer of abstraction between the loader and its plugins (because that's the whole point of having the extra class!). The plugins now only implement a load_chunks() function, which is much simpler to implement and allows plugins to play fast and loose with what they actually return. Basically, they can return many chunks of samples, where one chunk is simply a convenient block of samples to load. In fact, some loaders such as FLAC and QOA have separate internal functions for loading exactly one chunk. The loaders *should* load as many chunks as necessary for the sample count to be reached or surpassed (the latter simplifies loading loops in the implementations, since you don't need to know how large your next chunk is going to be; a problem for e.g. FLAC). If a plugin has no problems returning data of arbitrary size (currently WAV), it can return a single chunk that exactly (or roughly) matches the requested sample count. If a plugin is at the stream end, it can also return less samples than was requested! The loader can handle all of these cases and may call into load_chunk multiple times. If the plugin returns an empty chunk list (or only empty chunks; again, they can play fast and loose), the loader takes that as a stream end signal. Otherwise, the loader will always return exactly as many samples as the user requested. Buffering is handled by the loader, allowing any underlying plugin to deal with any weird sample count requirement the user throws at it (looking at you, SoundPlayer!). This (not accidentally!) makes QOA work in SoundPlayer.
2023-02-27 00:05:14 +01:00
}
sample_index += chunk.size();
}
}
return samples;
}
}