beenull/ladybird
1
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2024-11-29 02:50:26 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 6
ladybird/Userland/Libraries/LibAudio/WavLoader.cpp

287 lines
10 KiB
C++
Raw Normal View History

Meta: Add license header to source files As suggested by Joshua, this commit adds the 2-clause BSD license as a comment block to the top of every source file. For the first pass, I've just added myself for simplicity. I encourage everyone to add themselves as copyright holders of any file they've added or modified in some significant way. If I've added myself in error somewhere, feel free to replace it with the appropriate copyright holder instead. Going forward, all new source files should include a license header.
2020-01-18 08:38:21 +00:00
/*
* Copyright (c) 2018-2020, Andreas Kling <kling@serenityos.org>
Everywhere: Use my new serenityos.org e-mail :^)
2022-01-13 11:07:00 +00:00
* Copyright (c) 2021, kleines Filmröllchen <filmroellchen@serenityos.org>
Meta: Add license header to source files As suggested by Joshua, this commit adds the 2-clause BSD license as a comment block to the top of every source file. For the first pass, I've just added myself for simplicity. I encourage everyone to add themselves as copyright holders of any file they've added or modified in some significant way. If I've added myself in error somewhere, feel free to replace it with the appropriate copyright holder instead. Going forward, all new source files should include a license header.
2020-01-18 08:38:21 +00:00
*
Everything: Move to SPDX license identifiers in all files. 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 *
2021-04-22 08:24:48 +00:00
* SPDX-License-Identifier: BSD-2-Clause
Meta: Add license header to source files As suggested by Joshua, this commit adds the 2-clause BSD license as a comment block to the top of every source file. For the first pass, I've just added myself for simplicity. I encourage everyone to add themselves as copyright holders of any file they've added or modified in some significant way. If I've added myself in error somewhere, feel free to replace it with the appropriate copyright holder instead. Going forward, all new source files should include a license header.
2020-01-18 08:38:21 +00:00
*/
LibAudio: Make ResampleHelper templated for different sample types Previously, ResampleHelper was fixed on handling double's, which makes it unsuitable for the upcoming FLAC loader that needs to resample integers. For this reason, ResampleHelper is templated to support theoretically any type of sample, though only the necessary i32 and double are templated right now. The ResampleHelper implementations are moved from WavLoader.cpp to Buffer.cpp. This also improves some imports in the WavLoader files.
2021-06-25 11:37:38 +00:00
#include "WavLoader.h"
#include "Buffer.h"
Everywhere: Hook up remaining debug macros to Debug.h.
2021-01-24 14:28:26 +00:00
#include <AK/Debug.h>
LibAudio+Userland: Use new audio queue in client-server communication Previously, we were sending Buffers to the server whenever we had new audio data for it. This meant that for every audio enqueue action, we needed to create a new shared memory anonymous buffer, send that buffer's file descriptor over IPC (+recfd on the other side) and then map the buffer into the audio server's memory to be able to play it. This was fine for sending large chunks of audio data, like when playing existing audio files. However, in the future we want to move to real-time audio in some applications like Piano. This means that the size of buffers that are sent need to be very small, as just the size of a buffer itself is part of the audio latency. If we were to try real-time audio with the existing system, we would run into problems really quickly. Dealing with a continuous stream of new anonymous files like the current audio system is rather expensive, as we need Kernel help in multiple places. Additionally, every enqueue incurs an IPC call, which are not optimized for >1000 calls/second (which would be needed for real-time audio with buffer sizes of ~40 samples). So a fundamental change in how we handle audio sending in userspace is necessary. This commit moves the audio sending system onto a shared single producer circular queue (SSPCQ) (introduced with one of the previous commits). This queue is intended to live in shared memory and be accessed by multiple processes at the same time. It was specifically written to support the audio sending case, so e.g. it only supports a single producer (the audio client). Now, audio sending follows these general steps: - The audio client connects to the audio server. - The audio client creates a SSPCQ in shared memory. - The audio client sends the SSPCQ's file descriptor to the audio server with the set_buffer() IPC call. - The audio server receives the SSPCQ and maps it. - The audio client signals start of playback with start_playback(). - At the same time: - The audio client writes its audio data into the shared-memory queue. - The audio server reads audio data from the shared-memory queue(s). Both sides have additional before-queue/after-queue buffers, depending on the exact application. - Pausing playback is just an IPC call, nothing happens to the buffer except that the server stops reading from it until playback is resumed. - Muting has nothing to do with whether audio data is read or not. - When the connection closes, the queues are unmapped on both sides. This should already improve audio playback performance in a bunch of places. Implementation & commit notes: - Audio loaders don't create LegacyBuffers anymore. LegacyBuffer is kept for WavLoader, see previous commit message. - Most intra-process audio data passing is done with FixedArray<Sample> or Vector<Sample>. - Improvements to most audio-enqueuing applications. (If necessary I can try to extract some of the aplay improvements.) - New APIs on LibAudio/ClientConnection which allows non-realtime applications to enqueue audio in big chunks like before. - Removal of status APIs from the audio server connection for information that can be directly obtained from the shared queue. - Split the pause playback API into two APIs with more intuitive names. I know this is a large commit, and you can kinda tell from the commit message. It's basically impossible to break this up without hacks, so please forgive me. These are some of the best changes to the audio subsystem and I hope that that makes up for this :yaktangle: commit. :yakring:
2022-02-20 12:01:22 +00:00
#include <AK/FixedArray.h>
LibAudio: Use NumericLimits<T>
2020-04-15 14:52:04 +00:00
#include <AK/NumericLimits.h>
LibCore: Add a forward declaration header This patch adds <LibCore/Forward.h> and uses it in various places to shrink the header dependency graph.
2020-02-14 21:29:06 +00:00
#include <AK/OwnPtr.h>
LibAudio: New error propagation API in Loader and Buffer Previously, a libc-like out-of-line error information was used in the loader and its plugins. Now, all functions that may fail to do their job return some sort of Result. The universally-used error type ist the new LoaderError, which can contain information about the general error category (such as file format, I/O, unimplemented features), an error description, and location information, such as file index or sample index. Additionally, the loader plugins try to do as little work as possible in their constructors. Right after being constructed, a user should call initialize() and check the errors returned from there. (This is done transparently by Loader itself.) If a constructor caused an error, the call to initialize should check and return it immediately. This opportunity was used to rework a lot of the internal error propagation in both loader classes, especially FlacLoader. Therefore, a couple of other refactorings may have sneaked in as well. The adoption of LibAudio users is minimal. Piano's adoption is not important, as the code will receive major refactoring in the near future anyways. SoundPlayer's adoption is also less important, as changes to refactor it are in the works as well. aplay's adoption is the best and may serve as an example for other users. It also includes new buffering behavior. Buffer also gets some attention, making it OOM-safe and thereby also propagating its errors to the user.
2021-11-27 16:00:19 +00:00
#include <AK/Try.h>
LibCore: Remove leading C from filenames
2020-02-06 14:04:03 +00:00
#include <LibCore/File.h>
LibAudio+LibCore: Remove unnecessary IODeviceStreamReader.h IODeviceStreamReader isn't pulling its weight. It's essentially a subset of InputFileStream with only one user (WavLoader). This refactors WavLoader to use InputFileStream instead.
2021-06-05 16:38:43 +00:00
#include <LibCore/FileStream.h>
AudioServer: Assorted infrastructure work * Add a LibAudio, and move WAV file parsing there (via AWavFile and AWavLoader) * Add CLocalSocket, and CSocket::connect() variant for local address types. We make some small use of this in WindowServer (as that's where we modelled it from), but don't get too invasive as this PR is already quite large, and the WS I/O is a bit carefully done * Add an AClientConnection which will eventually be used to talk to AudioServer (and make use of it in Piano, though right now it really doesn't do anything except connect, using our new CLocalSocket...)
2019-07-13 17:42:03 +00:00
LibAudio: Put all classes in the Audio namespace and remove leading A
2020-02-06 09:40:02 +00:00
namespace Audio {
LibAudio: decrease WavLoader's size limit to a more reasonable size A 4 GiB wav (current size limit) is very unreasonable, and larger than oss-fuzz's 2.5 GiB per-process memory limit.
2021-03-16 17:05:59 +00:00
static constexpr size_t maximum_wav_size = 1 * GiB; // FIXME: is there a more appropriate size limit?
Everywhere: Pass AK::StringView by value
2021-11-10 23:55:02 +00:00
WavLoaderPlugin::WavLoaderPlugin(StringView path)
LibCore: Put all classes in the Core namespace and remove the leading C I've been wanting to do this for a long time. It's time we start being consistent about how this stuff works. The new convention is: - "LibFoo" is a userspace library that provides the "Foo" namespace. That's it :^) This was pretty tedious to convert and I didn't even start on LibGUI yet. But it's coming up next.
2020-02-02 11:34:39 +00:00
: m_file(Core::File::construct(path))
AudioServer: Assorted infrastructure work * Add a LibAudio, and move WAV file parsing there (via AWavFile and AWavLoader) * Add CLocalSocket, and CSocket::connect() variant for local address types. We make some small use of this in WindowServer (as that's where we modelled it from), but don't get too invasive as this PR is already quite large, and the WS I/O is a bit carefully done * Add an AClientConnection which will eventually be used to talk to AudioServer (and make use of it in Piano, though right now it really doesn't do anything except connect, using our new CLocalSocket...)
2019-07-13 17:42:03 +00:00
{
LibCore+Everywhere: Move OpenMode out of IODevice ...and make it an enum class so people don't omit "OpenMode".
2021-05-12 09:26:43 +00:00
if (!m_file->open(Core::OpenMode::ReadOnly)) {
LibAudio: New error propagation API in Loader and Buffer Previously, a libc-like out-of-line error information was used in the loader and its plugins. Now, all functions that may fail to do their job return some sort of Result. The universally-used error type ist the new LoaderError, which can contain information about the general error category (such as file format, I/O, unimplemented features), an error description, and location information, such as file index or sample index. Additionally, the loader plugins try to do as little work as possible in their constructors. Right after being constructed, a user should call initialize() and check the errors returned from there. (This is done transparently by Loader itself.) If a constructor caused an error, the call to initialize should check and return it immediately. This opportunity was used to rework a lot of the internal error propagation in both loader classes, especially FlacLoader. Therefore, a couple of other refactorings may have sneaked in as well. The adoption of LibAudio users is minimal. Piano's adoption is not important, as the code will receive major refactoring in the near future anyways. SoundPlayer's adoption is also less important, as changes to refactor it are in the works as well. aplay's adoption is the best and may serve as an example for other users. It also includes new buffering behavior. Buffer also gets some attention, making it OOM-safe and thereby also propagating its errors to the user.
2021-11-27 16:00:19 +00:00
m_error = LoaderError { String::formatted("Can't open file: {}", m_file->error_string()) };
Audio: Make basic streaming WAV playback work. I had to solve a bunch of things simultaneously to make this work. Refactor AWavLoader to be a streaming loader rather than a one-shot one. The constructor parses the header, and if everything looks good, you can repeatedly ask the AWavLoader for sample buffers until it runs out. Also send a message from AudioServer when a buffer has finished playing. That allows us to implement a blocking variant of play(). Use all of this in aplay to play WAV files chunk-at-a-time. This is definitely not perfect and it's a little glitchy and skippy, but I think it's a step in the right direction.
2019-07-27 15:20:41 +00:00
return;
AudioServer: Assorted infrastructure work * Add a LibAudio, and move WAV file parsing there (via AWavFile and AWavLoader) * Add CLocalSocket, and CSocket::connect() variant for local address types. We make some small use of this in WindowServer (as that's where we modelled it from), but don't get too invasive as this PR is already quite large, and the WS I/O is a bit carefully done * Add an AClientConnection which will eventually be used to talk to AudioServer (and make use of it in Piano, though right now it really doesn't do anything except connect, using our new CLocalSocket...)
2019-07-13 17:42:03 +00:00
}
LibAudio: WavLoader: Avoid reading partial samples When samples are requested in `Audio::Loader::get_more_samples`, the request comes in as a max number of bytes to read. However, the requested number of bytes may not be an even multiple of the bytes per sample of the loaded file. If this is the case, and the bytes are read from the file/stream, then the last sample will be a partial/runt sample, which then offsets the remainder of the stream, causing white noise in playback. This bug was discovered when trying to play 24-bit Wave files, which happened to have a sample size that never aligned with the number of requested bytes. This commit fixes the bug by only reading a multiple of "bytes per sample" for the loaded file.
2021-06-05 17:14:03 +00:00
m_stream = make<Core::InputFileStream>(*m_file);
LibAudio: New error propagation API in Loader and Buffer Previously, a libc-like out-of-line error information was used in the loader and its plugins. Now, all functions that may fail to do their job return some sort of Result. The universally-used error type ist the new LoaderError, which can contain information about the general error category (such as file format, I/O, unimplemented features), an error description, and location information, such as file index or sample index. Additionally, the loader plugins try to do as little work as possible in their constructors. Right after being constructed, a user should call initialize() and check the errors returned from there. (This is done transparently by Loader itself.) If a constructor caused an error, the call to initialize should check and return it immediately. This opportunity was used to rework a lot of the internal error propagation in both loader classes, especially FlacLoader. Therefore, a couple of other refactorings may have sneaked in as well. The adoption of LibAudio users is minimal. Piano's adoption is not important, as the code will receive major refactoring in the near future anyways. SoundPlayer's adoption is also less important, as changes to refactor it are in the works as well. aplay's adoption is the best and may serve as an example for other users. It also includes new buffering behavior. Buffer also gets some attention, making it OOM-safe and thereby also propagating its errors to the user.
2021-11-27 16:00:19 +00:00
}
AudioServer: Assorted infrastructure work * Add a LibAudio, and move WAV file parsing there (via AWavFile and AWavLoader) * Add CLocalSocket, and CSocket::connect() variant for local address types. We make some small use of this in WindowServer (as that's where we modelled it from), but don't get too invasive as this PR is already quite large, and the WS I/O is a bit carefully done * Add an AClientConnection which will eventually be used to talk to AudioServer (and make use of it in Piano, though right now it really doesn't do anything except connect, using our new CLocalSocket...)
2019-07-13 17:42:03 +00:00
LibAudio: New error propagation API in Loader and Buffer Previously, a libc-like out-of-line error information was used in the loader and its plugins. Now, all functions that may fail to do their job return some sort of Result. The universally-used error type ist the new LoaderError, which can contain information about the general error category (such as file format, I/O, unimplemented features), an error description, and location information, such as file index or sample index. Additionally, the loader plugins try to do as little work as possible in their constructors. Right after being constructed, a user should call initialize() and check the errors returned from there. (This is done transparently by Loader itself.) If a constructor caused an error, the call to initialize should check and return it immediately. This opportunity was used to rework a lot of the internal error propagation in both loader classes, especially FlacLoader. Therefore, a couple of other refactorings may have sneaked in as well. The adoption of LibAudio users is minimal. Piano's adoption is not important, as the code will receive major refactoring in the near future anyways. SoundPlayer's adoption is also less important, as changes to refactor it are in the works as well. aplay's adoption is the best and may serve as an example for other users. It also includes new buffering behavior. Buffer also gets some attention, making it OOM-safe and thereby also propagating its errors to the user.
2021-11-27 16:00:19 +00:00
MaybeLoaderError WavLoaderPlugin::initialize()
{
if (m_error.has_value())
return m_error.release_value();
TRY(parse_header());
return {};
Audio: Make basic streaming WAV playback work. I had to solve a bunch of things simultaneously to make this work. Refactor AWavLoader to be a streaming loader rather than a one-shot one. The constructor parses the header, and if everything looks good, you can repeatedly ask the AWavLoader for sample buffers until it runs out. Also send a message from AudioServer when a buffer has finished playing. That allows us to implement a blocking variant of play(). Use all of this in aplay to play WAV files chunk-at-a-time. This is definitely not perfect and it's a little glitchy and skippy, but I think it's a step in the right direction.
2019-07-27 15:20:41 +00:00
}
Everywhere: Run clang-format
2022-04-01 17:58:27 +00:00
WavLoaderPlugin::WavLoaderPlugin(Bytes const& buffer)
LibAudio: Allow loading sounds from memory The Loader and WavLoaderPlugin classes now have methods for loading from a ByteBuffer, in addition to streaming from disk.
2020-12-02 14:44:45 +00:00
{
m_stream = make<InputMemoryStream>(buffer);
if (!m_stream) {
LibAudio: New error propagation API in Loader and Buffer Previously, a libc-like out-of-line error information was used in the loader and its plugins. Now, all functions that may fail to do their job return some sort of Result. The universally-used error type ist the new LoaderError, which can contain information about the general error category (such as file format, I/O, unimplemented features), an error description, and location information, such as file index or sample index. Additionally, the loader plugins try to do as little work as possible in their constructors. Right after being constructed, a user should call initialize() and check the errors returned from there. (This is done transparently by Loader itself.) If a constructor caused an error, the call to initialize should check and return it immediately. This opportunity was used to rework a lot of the internal error propagation in both loader classes, especially FlacLoader. Therefore, a couple of other refactorings may have sneaked in as well. The adoption of LibAudio users is minimal. Piano's adoption is not important, as the code will receive major refactoring in the near future anyways. SoundPlayer's adoption is also less important, as changes to refactor it are in the works as well. aplay's adoption is the best and may serve as an example for other users. It also includes new buffering behavior. Buffer also gets some attention, making it OOM-safe and thereby also propagating its errors to the user.
2021-11-27 16:00:19 +00:00
m_error = LoaderError { String::formatted("Can't open memory stream") };
LibAudio: Allow loading sounds from memory The Loader and WavLoaderPlugin classes now have methods for loading from a ByteBuffer, in addition to streaming from disk.
2020-12-02 14:44:45 +00:00
return;
}
LibAudio: WavLoader: Avoid reading partial samples When samples are requested in `Audio::Loader::get_more_samples`, the request comes in as a max number of bytes to read. However, the requested number of bytes may not be an even multiple of the bytes per sample of the loaded file. If this is the case, and the bytes are read from the file/stream, then the last sample will be a partial/runt sample, which then offsets the remainder of the stream, causing white noise in playback. This bug was discovered when trying to play 24-bit Wave files, which happened to have a sample size that never aligned with the number of requested bytes. This commit fixes the bug by only reading a multiple of "bytes per sample" for the loaded file.
2021-06-05 17:14:03 +00:00
m_memory_stream = static_cast<InputMemoryStream*>(m_stream.ptr());
LibAudio: Allow loading sounds from memory The Loader and WavLoaderPlugin classes now have methods for loading from a ByteBuffer, in addition to streaming from disk.
2020-12-02 14:44:45 +00:00
}
LibAudio: New error propagation API in Loader and Buffer Previously, a libc-like out-of-line error information was used in the loader and its plugins. Now, all functions that may fail to do their job return some sort of Result. The universally-used error type ist the new LoaderError, which can contain information about the general error category (such as file format, I/O, unimplemented features), an error description, and location information, such as file index or sample index. Additionally, the loader plugins try to do as little work as possible in their constructors. Right after being constructed, a user should call initialize() and check the errors returned from there. (This is done transparently by Loader itself.) If a constructor caused an error, the call to initialize should check and return it immediately. This opportunity was used to rework a lot of the internal error propagation in both loader classes, especially FlacLoader. Therefore, a couple of other refactorings may have sneaked in as well. The adoption of LibAudio users is minimal. Piano's adoption is not important, as the code will receive major refactoring in the near future anyways. SoundPlayer's adoption is also less important, as changes to refactor it are in the works as well. aplay's adoption is the best and may serve as an example for other users. It also includes new buffering behavior. Buffer also gets some attention, making it OOM-safe and thereby also propagating its errors to the user.
2021-11-27 16:00:19 +00:00
LoaderSamples WavLoaderPlugin::get_more_samples(size_t max_bytes_to_read_from_input)
Audio: Make basic streaming WAV playback work. I had to solve a bunch of things simultaneously to make this work. Refactor AWavLoader to be a streaming loader rather than a one-shot one. The constructor parses the header, and if everything looks good, you can repeatedly ask the AWavLoader for sample buffers until it runs out. Also send a message from AudioServer when a buffer has finished playing. That allows us to implement a blocking variant of play(). Use all of this in aplay to play WAV files chunk-at-a-time. This is definitely not perfect and it's a little glitchy and skippy, but I think it's a step in the right direction.
2019-07-27 15:20:41 +00:00
{
LibAudio: WavLoader: Avoid reading partial samples When samples are requested in `Audio::Loader::get_more_samples`, the request comes in as a max number of bytes to read. However, the requested number of bytes may not be an even multiple of the bytes per sample of the loaded file. If this is the case, and the bytes are read from the file/stream, then the last sample will be a partial/runt sample, which then offsets the remainder of the stream, causing white noise in playback. This bug was discovered when trying to play 24-bit Wave files, which happened to have a sample size that never aligned with the number of requested bytes. This commit fixes the bug by only reading a multiple of "bytes per sample" for the loaded file.
2021-06-05 17:14:03 +00:00
if (!m_stream)
LibAudio: New error propagation API in Loader and Buffer Previously, a libc-like out-of-line error information was used in the loader and its plugins. Now, all functions that may fail to do their job return some sort of Result. The universally-used error type ist the new LoaderError, which can contain information about the general error category (such as file format, I/O, unimplemented features), an error description, and location information, such as file index or sample index. Additionally, the loader plugins try to do as little work as possible in their constructors. Right after being constructed, a user should call initialize() and check the errors returned from there. (This is done transparently by Loader itself.) If a constructor caused an error, the call to initialize should check and return it immediately. This opportunity was used to rework a lot of the internal error propagation in both loader classes, especially FlacLoader. Therefore, a couple of other refactorings may have sneaked in as well. The adoption of LibAudio users is minimal. Piano's adoption is not important, as the code will receive major refactoring in the near future anyways. SoundPlayer's adoption is also less important, as changes to refactor it are in the works as well. aplay's adoption is the best and may serve as an example for other users. It also includes new buffering behavior. Buffer also gets some attention, making it OOM-safe and thereby also propagating its errors to the user.
2021-11-27 16:00:19 +00:00
return LoaderError { LoaderError::Category::Internal, static_cast<size_t>(m_loaded_samples), "No stream" };
LibAudio: WavLoader: Avoid reading partial samples When samples are requested in `Audio::Loader::get_more_samples`, the request comes in as a max number of bytes to read. However, the requested number of bytes may not be an even multiple of the bytes per sample of the loaded file. If this is the case, and the bytes are read from the file/stream, then the last sample will be a partial/runt sample, which then offsets the remainder of the stream, causing white noise in playback. This bug was discovered when trying to play 24-bit Wave files, which happened to have a sample size that never aligned with the number of requested bytes. This commit fixes the bug by only reading a multiple of "bytes per sample" for the loaded file.
2021-06-05 17:14:03 +00:00
LibAudio: Avoid reading past the end of sample data Prior code in `WavLoader::get_more_samples()` would attempt to read the requested number of samples without actually checking whether that many samples were remaining in the stream. This was the cause of an audible pop at the end of a track, due to reading non-audio data that is sometimes at the end of a Wave file. Now we only attempt to read up to the end of sample data, but no further. Also, added comments to clarify the meaning of "sample", and how it should be independent of the number of channels.
2021-06-10 17:59:00 +00:00
int remaining_samples = m_total_samples - m_loaded_samples;
LibAudio: New error propagation API in Loader and Buffer Previously, a libc-like out-of-line error information was used in the loader and its plugins. Now, all functions that may fail to do their job return some sort of Result. The universally-used error type ist the new LoaderError, which can contain information about the general error category (such as file format, I/O, unimplemented features), an error description, and location information, such as file index or sample index. Additionally, the loader plugins try to do as little work as possible in their constructors. Right after being constructed, a user should call initialize() and check the errors returned from there. (This is done transparently by Loader itself.) If a constructor caused an error, the call to initialize should check and return it immediately. This opportunity was used to rework a lot of the internal error propagation in both loader classes, especially FlacLoader. Therefore, a couple of other refactorings may have sneaked in as well. The adoption of LibAudio users is minimal. Piano's adoption is not important, as the code will receive major refactoring in the near future anyways. SoundPlayer's adoption is also less important, as changes to refactor it are in the works as well. aplay's adoption is the best and may serve as an example for other users. It also includes new buffering behavior. Buffer also gets some attention, making it OOM-safe and thereby also propagating its errors to the user.
2021-11-27 16:00:19 +00:00
if (remaining_samples <= 0)
LibAudio+Userland: Use new audio queue in client-server communication Previously, we were sending Buffers to the server whenever we had new audio data for it. This meant that for every audio enqueue action, we needed to create a new shared memory anonymous buffer, send that buffer's file descriptor over IPC (+recfd on the other side) and then map the buffer into the audio server's memory to be able to play it. This was fine for sending large chunks of audio data, like when playing existing audio files. However, in the future we want to move to real-time audio in some applications like Piano. This means that the size of buffers that are sent need to be very small, as just the size of a buffer itself is part of the audio latency. If we were to try real-time audio with the existing system, we would run into problems really quickly. Dealing with a continuous stream of new anonymous files like the current audio system is rather expensive, as we need Kernel help in multiple places. Additionally, every enqueue incurs an IPC call, which are not optimized for >1000 calls/second (which would be needed for real-time audio with buffer sizes of ~40 samples). So a fundamental change in how we handle audio sending in userspace is necessary. This commit moves the audio sending system onto a shared single producer circular queue (SSPCQ) (introduced with one of the previous commits). This queue is intended to live in shared memory and be accessed by multiple processes at the same time. It was specifically written to support the audio sending case, so e.g. it only supports a single producer (the audio client). Now, audio sending follows these general steps: - The audio client connects to the audio server. - The audio client creates a SSPCQ in shared memory. - The audio client sends the SSPCQ's file descriptor to the audio server with the set_buffer() IPC call. - The audio server receives the SSPCQ and maps it. - The audio client signals start of playback with start_playback(). - At the same time: - The audio client writes its audio data into the shared-memory queue. - The audio server reads audio data from the shared-memory queue(s). Both sides have additional before-queue/after-queue buffers, depending on the exact application. - Pausing playback is just an IPC call, nothing happens to the buffer except that the server stops reading from it until playback is resumed. - Muting has nothing to do with whether audio data is read or not. - When the connection closes, the queues are unmapped on both sides. This should already improve audio playback performance in a bunch of places. Implementation & commit notes: - Audio loaders don't create LegacyBuffers anymore. LegacyBuffer is kept for WavLoader, see previous commit message. - Most intra-process audio data passing is done with FixedArray<Sample> or Vector<Sample>. - Improvements to most audio-enqueuing applications. (If necessary I can try to extract some of the aplay improvements.) - New APIs on LibAudio/ClientConnection which allows non-realtime applications to enqueue audio in big chunks like before. - Removal of status APIs from the audio server connection for information that can be directly obtained from the shared queue. - Split the pause playback API into two APIs with more intuitive names. I know this is a large commit, and you can kinda tell from the commit message. It's basically impossible to break this up without hacks, so please forgive me. These are some of the best changes to the audio subsystem and I hope that that makes up for this :yaktangle: commit. :yakring:
2022-02-20 12:01:22 +00:00
return FixedArray<Sample> {};
LibAudio: WavLoader: Avoid reading partial samples When samples are requested in `Audio::Loader::get_more_samples`, the request comes in as a max number of bytes to read. However, the requested number of bytes may not be an even multiple of the bytes per sample of the loaded file. If this is the case, and the bytes are read from the file/stream, then the last sample will be a partial/runt sample, which then offsets the remainder of the stream, causing white noise in playback. This bug was discovered when trying to play 24-bit Wave files, which happened to have a sample size that never aligned with the number of requested bytes. This commit fixes the bug by only reading a multiple of "bytes per sample" for the loaded file.
2021-06-05 17:14:03 +00:00
LibAudio: Avoid reading past the end of sample data Prior code in `WavLoader::get_more_samples()` would attempt to read the requested number of samples without actually checking whether that many samples were remaining in the stream. This was the cause of an audible pop at the end of a track, due to reading non-audio data that is sometimes at the end of a Wave file. Now we only attempt to read up to the end of sample data, but no further. Also, added comments to clarify the meaning of "sample", and how it should be independent of the number of channels.
2021-06-10 17:59:00 +00:00
// One "sample" contains data from all channels.
// In the Wave spec, this is also called a block.
LibAudio: New error propagation API in Loader and Buffer Previously, a libc-like out-of-line error information was used in the loader and its plugins. Now, all functions that may fail to do their job return some sort of Result. The universally-used error type ist the new LoaderError, which can contain information about the general error category (such as file format, I/O, unimplemented features), an error description, and location information, such as file index or sample index. Additionally, the loader plugins try to do as little work as possible in their constructors. Right after being constructed, a user should call initialize() and check the errors returned from there. (This is done transparently by Loader itself.) If a constructor caused an error, the call to initialize should check and return it immediately. This opportunity was used to rework a lot of the internal error propagation in both loader classes, especially FlacLoader. Therefore, a couple of other refactorings may have sneaked in as well. The adoption of LibAudio users is minimal. Piano's adoption is not important, as the code will receive major refactoring in the near future anyways. SoundPlayer's adoption is also less important, as changes to refactor it are in the works as well. aplay's adoption is the best and may serve as an example for other users. It also includes new buffering behavior. Buffer also gets some attention, making it OOM-safe and thereby also propagating its errors to the user.
2021-11-27 16:00:19 +00:00
size_t bytes_per_sample
= m_num_channels * pcm_bits_per_sample(m_sample_format) / 8;
LibAudio: Avoid reading past the end of sample data Prior code in `WavLoader::get_more_samples()` would attempt to read the requested number of samples without actually checking whether that many samples were remaining in the stream. This was the cause of an audible pop at the end of a track, due to reading non-audio data that is sometimes at the end of a Wave file. Now we only attempt to read up to the end of sample data, but no further. Also, added comments to clarify the meaning of "sample", and how it should be independent of the number of channels.
2021-06-10 17:59:00 +00:00
// Might truncate if not evenly divisible by the sample size
int max_samples_to_read = static_cast<int>(max_bytes_to_read_from_input) / bytes_per_sample;
int samples_to_read = min(max_samples_to_read, remaining_samples);
LibAudio: WavLoader: Avoid reading partial samples When samples are requested in `Audio::Loader::get_more_samples`, the request comes in as a max number of bytes to read. However, the requested number of bytes may not be an even multiple of the bytes per sample of the loaded file. If this is the case, and the bytes are read from the file/stream, then the last sample will be a partial/runt sample, which then offsets the remainder of the stream, causing white noise in playback. This bug was discovered when trying to play 24-bit Wave files, which happened to have a sample size that never aligned with the number of requested bytes. This commit fixes the bug by only reading a multiple of "bytes per sample" for the loaded file.
2021-06-05 17:14:03 +00:00
size_t bytes_to_read = samples_to_read * bytes_per_sample;
LibAudio: Avoid reading past the end of sample data Prior code in `WavLoader::get_more_samples()` would attempt to read the requested number of samples without actually checking whether that many samples were remaining in the stream. This was the cause of an audible pop at the end of a track, due to reading non-audio data that is sometimes at the end of a Wave file. Now we only attempt to read up to the end of sample data, but no further. Also, added comments to clarify the meaning of "sample", and how it should be independent of the number of channels.
2021-06-10 17:59:00 +00:00
dbgln_if(AWAVLOADER_DEBUG, "Read {} bytes WAV with num_channels {} sample rate {}, "
Everywhere: Turn #if *_DEBUG into dbgln_if/if constexpr
2021-05-01 19:10:08 +00:00
"bits per sample {}, sample format {}",
LibAudio: Avoid reading past the end of sample data Prior code in `WavLoader::get_more_samples()` would attempt to read the requested number of samples without actually checking whether that many samples were remaining in the stream. This was the cause of an audible pop at the end of a track, due to reading non-audio data that is sometimes at the end of a Wave file. Now we only attempt to read up to the end of sample data, but no further. Also, added comments to clarify the meaning of "sample", and how it should be independent of the number of channels.
2021-06-10 17:59:00 +00:00
bytes_to_read, m_num_channels, m_sample_rate,
LibAudio: WavLoader: Avoid reading partial samples When samples are requested in `Audio::Loader::get_more_samples`, the request comes in as a max number of bytes to read. However, the requested number of bytes may not be an even multiple of the bytes per sample of the loaded file. If this is the case, and the bytes are read from the file/stream, then the last sample will be a partial/runt sample, which then offsets the remainder of the stream, causing white noise in playback. This bug was discovered when trying to play 24-bit Wave files, which happened to have a sample size that never aligned with the number of requested bytes. This commit fixes the bug by only reading a multiple of "bytes per sample" for the loaded file.
2021-06-05 17:14:03 +00:00
pcm_bits_per_sample(m_sample_format), sample_format_name(m_sample_format));
Everywhere: Make ByteBuffer::{create_*,copy}() OOM-safe
2021-09-05 22:59:52 +00:00
auto sample_data_result = ByteBuffer::create_zeroed(bytes_to_read);
Everywhere: Convert ByteBuffer factory methods from Optional -> ErrorOr Apologies for the enormous commit, but I don't see a way to split this up nicely. In the vast majority of cases it's a simple change. A few extra places can use TRY instead of manual error checking though. :^)
2022-01-20 17:47:39 +00:00
if (sample_data_result.is_error())
LibAudio: New error propagation API in Loader and Buffer Previously, a libc-like out-of-line error information was used in the loader and its plugins. Now, all functions that may fail to do their job return some sort of Result. The universally-used error type ist the new LoaderError, which can contain information about the general error category (such as file format, I/O, unimplemented features), an error description, and location information, such as file index or sample index. Additionally, the loader plugins try to do as little work as possible in their constructors. Right after being constructed, a user should call initialize() and check the errors returned from there. (This is done transparently by Loader itself.) If a constructor caused an error, the call to initialize should check and return it immediately. This opportunity was used to rework a lot of the internal error propagation in both loader classes, especially FlacLoader. Therefore, a couple of other refactorings may have sneaked in as well. The adoption of LibAudio users is minimal. Piano's adoption is not important, as the code will receive major refactoring in the near future anyways. SoundPlayer's adoption is also less important, as changes to refactor it are in the works as well. aplay's adoption is the best and may serve as an example for other users. It also includes new buffering behavior. Buffer also gets some attention, making it OOM-safe and thereby also propagating its errors to the user.
2021-11-27 16:00:19 +00:00
return LoaderError { LoaderError::Category::IO, static_cast<size_t>(m_loaded_samples), "Couldn't allocate sample buffer" };
Everywhere: Make ByteBuffer::{create_*,copy}() OOM-safe
2021-09-05 22:59:52 +00:00
auto sample_data = sample_data_result.release_value();
LibAudio: WavLoader: Avoid reading partial samples When samples are requested in `Audio::Loader::get_more_samples`, the request comes in as a max number of bytes to read. However, the requested number of bytes may not be an even multiple of the bytes per sample of the loaded file. If this is the case, and the bytes are read from the file/stream, then the last sample will be a partial/runt sample, which then offsets the remainder of the stream, causing white noise in playback. This bug was discovered when trying to play 24-bit Wave files, which happened to have a sample size that never aligned with the number of requested bytes. This commit fixes the bug by only reading a multiple of "bytes per sample" for the loaded file.
2021-06-05 17:14:03 +00:00
m_stream->read_or_error(sample_data.bytes());
LibAudio: New error propagation API in Loader and Buffer Previously, a libc-like out-of-line error information was used in the loader and its plugins. Now, all functions that may fail to do their job return some sort of Result. The universally-used error type ist the new LoaderError, which can contain information about the general error category (such as file format, I/O, unimplemented features), an error description, and location information, such as file index or sample index. Additionally, the loader plugins try to do as little work as possible in their constructors. Right after being constructed, a user should call initialize() and check the errors returned from there. (This is done transparently by Loader itself.) If a constructor caused an error, the call to initialize should check and return it immediately. This opportunity was used to rework a lot of the internal error propagation in both loader classes, especially FlacLoader. Therefore, a couple of other refactorings may have sneaked in as well. The adoption of LibAudio users is minimal. Piano's adoption is not important, as the code will receive major refactoring in the near future anyways. SoundPlayer's adoption is also less important, as changes to refactor it are in the works as well. aplay's adoption is the best and may serve as an example for other users. It also includes new buffering behavior. Buffer also gets some attention, making it OOM-safe and thereby also propagating its errors to the user.
2021-11-27 16:00:19 +00:00
if (m_stream->handle_any_error())
return LoaderError { LoaderError::Category::IO, static_cast<size_t>(m_loaded_samples), "Stream read error" };
LibAudio: WavLoader: Avoid reading partial samples When samples are requested in `Audio::Loader::get_more_samples`, the request comes in as a max number of bytes to read. However, the requested number of bytes may not be an even multiple of the bytes per sample of the loaded file. If this is the case, and the bytes are read from the file/stream, then the last sample will be a partial/runt sample, which then offsets the remainder of the stream, causing white noise in playback. This bug was discovered when trying to play 24-bit Wave files, which happened to have a sample size that never aligned with the number of requested bytes. This commit fixes the bug by only reading a multiple of "bytes per sample" for the loaded file.
2021-06-05 17:14:03 +00:00
LibAudio+Everywhere: Rename Audio::Buffer -> Audio::LegacyBuffer With the following change in how we send audio, the old Buffer type is not really needed anymore. However, moving WavLoader to the new system is a bit more involved and out of the scope of this PR. Therefore, we need to keep Buffer around, but to make it clear that it's the old buffer type which will be removed soon, we rename it to LegacyBuffer. Most of the users will be gone after the next commit anyways.
2022-02-20 12:18:38 +00:00
auto buffer = LegacyBuffer::from_pcm_data(
LibAudio: WavLoader: Avoid reading partial samples When samples are requested in `Audio::Loader::get_more_samples`, the request comes in as a max number of bytes to read. However, the requested number of bytes may not be an even multiple of the bytes per sample of the loaded file. If this is the case, and the bytes are read from the file/stream, then the last sample will be a partial/runt sample, which then offsets the remainder of the stream, causing white noise in playback. This bug was discovered when trying to play 24-bit Wave files, which happened to have a sample size that never aligned with the number of requested bytes. This commit fixes the bug by only reading a multiple of "bytes per sample" for the loaded file.
2021-06-05 17:14:03 +00:00
sample_data.bytes(),
m_num_channels,
m_sample_format);
LibAudio: New error propagation API in Loader and Buffer Previously, a libc-like out-of-line error information was used in the loader and its plugins. Now, all functions that may fail to do their job return some sort of Result. The universally-used error type ist the new LoaderError, which can contain information about the general error category (such as file format, I/O, unimplemented features), an error description, and location information, such as file index or sample index. Additionally, the loader plugins try to do as little work as possible in their constructors. Right after being constructed, a user should call initialize() and check the errors returned from there. (This is done transparently by Loader itself.) If a constructor caused an error, the call to initialize should check and return it immediately. This opportunity was used to rework a lot of the internal error propagation in both loader classes, especially FlacLoader. Therefore, a couple of other refactorings may have sneaked in as well. The adoption of LibAudio users is minimal. Piano's adoption is not important, as the code will receive major refactoring in the near future anyways. SoundPlayer's adoption is also less important, as changes to refactor it are in the works as well. aplay's adoption is the best and may serve as an example for other users. It also includes new buffering behavior. Buffer also gets some attention, making it OOM-safe and thereby also propagating its errors to the user.
2021-11-27 16:00:19 +00:00
if (buffer.is_error())
return LoaderError { LoaderError::Category::Internal, static_cast<size_t>(m_loaded_samples), "Couldn't allocate sample buffer" };
LibAudio: WavLoader: Avoid reading partial samples When samples are requested in `Audio::Loader::get_more_samples`, the request comes in as a max number of bytes to read. However, the requested number of bytes may not be an even multiple of the bytes per sample of the loaded file. If this is the case, and the bytes are read from the file/stream, then the last sample will be a partial/runt sample, which then offsets the remainder of the stream, causing white noise in playback. This bug was discovered when trying to play 24-bit Wave files, which happened to have a sample size that never aligned with the number of requested bytes. This commit fixes the bug by only reading a multiple of "bytes per sample" for the loaded file.
2021-06-05 17:14:03 +00:00
// m_loaded_samples should contain the amount of actually loaded samples
LibAudio: Allow loading sounds from memory The Loader and WavLoaderPlugin classes now have methods for loading from a ByteBuffer, in addition to streaming from disk.
2020-12-02 14:44:45 +00:00
m_loaded_samples += samples_to_read;
LibAudio+Userland: Use new audio queue in client-server communication Previously, we were sending Buffers to the server whenever we had new audio data for it. This meant that for every audio enqueue action, we needed to create a new shared memory anonymous buffer, send that buffer's file descriptor over IPC (+recfd on the other side) and then map the buffer into the audio server's memory to be able to play it. This was fine for sending large chunks of audio data, like when playing existing audio files. However, in the future we want to move to real-time audio in some applications like Piano. This means that the size of buffers that are sent need to be very small, as just the size of a buffer itself is part of the audio latency. If we were to try real-time audio with the existing system, we would run into problems really quickly. Dealing with a continuous stream of new anonymous files like the current audio system is rather expensive, as we need Kernel help in multiple places. Additionally, every enqueue incurs an IPC call, which are not optimized for >1000 calls/second (which would be needed for real-time audio with buffer sizes of ~40 samples). So a fundamental change in how we handle audio sending in userspace is necessary. This commit moves the audio sending system onto a shared single producer circular queue (SSPCQ) (introduced with one of the previous commits). This queue is intended to live in shared memory and be accessed by multiple processes at the same time. It was specifically written to support the audio sending case, so e.g. it only supports a single producer (the audio client). Now, audio sending follows these general steps: - The audio client connects to the audio server. - The audio client creates a SSPCQ in shared memory. - The audio client sends the SSPCQ's file descriptor to the audio server with the set_buffer() IPC call. - The audio server receives the SSPCQ and maps it. - The audio client signals start of playback with start_playback(). - At the same time: - The audio client writes its audio data into the shared-memory queue. - The audio server reads audio data from the shared-memory queue(s). Both sides have additional before-queue/after-queue buffers, depending on the exact application. - Pausing playback is just an IPC call, nothing happens to the buffer except that the server stops reading from it until playback is resumed. - Muting has nothing to do with whether audio data is read or not. - When the connection closes, the queues are unmapped on both sides. This should already improve audio playback performance in a bunch of places. Implementation & commit notes: - Audio loaders don't create LegacyBuffers anymore. LegacyBuffer is kept for WavLoader, see previous commit message. - Most intra-process audio data passing is done with FixedArray<Sample> or Vector<Sample>. - Improvements to most audio-enqueuing applications. (If necessary I can try to extract some of the aplay improvements.) - New APIs on LibAudio/ClientConnection which allows non-realtime applications to enqueue audio in big chunks like before. - Removal of status APIs from the audio server connection for information that can be directly obtained from the shared queue. - Split the pause playback API into two APIs with more intuitive names. I know this is a large commit, and you can kinda tell from the commit message. It's basically impossible to break this up without hacks, so please forgive me. These are some of the best changes to the audio subsystem and I hope that that makes up for this :yaktangle: commit. :yakring:
2022-02-20 12:01:22 +00:00
return LOADER_TRY(buffer.value()->to_sample_array());
AudioServer: Assorted infrastructure work * Add a LibAudio, and move WAV file parsing there (via AWavFile and AWavLoader) * Add CLocalSocket, and CSocket::connect() variant for local address types. We make some small use of this in WindowServer (as that's where we modelled it from), but don't get too invasive as this PR is already quite large, and the WS I/O is a bit carefully done * Add an AClientConnection which will eventually be used to talk to AudioServer (and make use of it in Piano, though right now it really doesn't do anything except connect, using our new CLocalSocket...)
2019-07-13 17:42:03 +00:00
}
Everywhere: Run clang-format
2022-04-01 17:58:27 +00:00
MaybeLoaderError WavLoaderPlugin::seek(int const sample_index)
LibAudio: Added playback control features to audio server LibAudio now supports pausing playback, clearing the buffer queue, retrieving the played samples since the last clear and retrieving the currently playing shared buffer id
2019-11-04 18:39:17 +00:00
{
LibAudio: Make Loader::seek() treat its input as a sample index This fixes a bug where if you try to play a Wave file a second time (or loop with `aplay -l`), the second time will be pure noise. The function `Audio::Loader::seek` is meant to seek to a specific audio sample, e.g. seek(0) should go to the first audio sample. However, WavLoader was interpreting seek(0) as the beginning of the file or stream, which contains non-audio header data. This fixes the bug by capturing the byte offset of the start of the audio data, and offseting the raw file/stream seek by that amount.
2021-06-06 00:14:55 +00:00
dbgln_if(AWAVLOADER_DEBUG, "seek sample_index {}", sample_index);
if (sample_index < 0 || sample_index >= m_total_samples)
LibAudio: New error propagation API in Loader and Buffer Previously, a libc-like out-of-line error information was used in the loader and its plugins. Now, all functions that may fail to do their job return some sort of Result. The universally-used error type ist the new LoaderError, which can contain information about the general error category (such as file format, I/O, unimplemented features), an error description, and location information, such as file index or sample index. Additionally, the loader plugins try to do as little work as possible in their constructors. Right after being constructed, a user should call initialize() and check the errors returned from there. (This is done transparently by Loader itself.) If a constructor caused an error, the call to initialize should check and return it immediately. This opportunity was used to rework a lot of the internal error propagation in both loader classes, especially FlacLoader. Therefore, a couple of other refactorings may have sneaked in as well. The adoption of LibAudio users is minimal. Piano's adoption is not important, as the code will receive major refactoring in the near future anyways. SoundPlayer's adoption is also less important, as changes to refactor it are in the works as well. aplay's adoption is the best and may serve as an example for other users. It also includes new buffering behavior. Buffer also gets some attention, making it OOM-safe and thereby also propagating its errors to the user.
2021-11-27 16:00:19 +00:00
return LoaderError { LoaderError::Category::Internal, static_cast<size_t>(m_loaded_samples), "Seek outside the sample range" };
LibAudio: Added playback control features to audio server LibAudio now supports pausing playback, clearing the buffer queue, retrieving the played samples since the last clear and retrieving the currently playing shared buffer id
2019-11-04 18:39:17 +00:00
LibAudio: Avoid reading past the end of sample data Prior code in `WavLoader::get_more_samples()` would attempt to read the requested number of samples without actually checking whether that many samples were remaining in the stream. This was the cause of an audible pop at the end of a track, due to reading non-audio data that is sometimes at the end of a Wave file. Now we only attempt to read up to the end of sample data, but no further. Also, added comments to clarify the meaning of "sample", and how it should be independent of the number of channels.
2021-06-10 17:59:00 +00:00
size_t sample_offset = m_byte_offset_of_data_samples + (sample_index * m_num_channels * (pcm_bits_per_sample(m_sample_format) / 8));
LibAudio: Allow loading sounds from memory The Loader and WavLoaderPlugin classes now have methods for loading from a ByteBuffer, in addition to streaming from disk.
2020-12-02 14:44:45 +00:00
LibAudio: Avoid reading past the end of sample data Prior code in `WavLoader::get_more_samples()` would attempt to read the requested number of samples without actually checking whether that many samples were remaining in the stream. This was the cause of an audible pop at the end of a track, due to reading non-audio data that is sometimes at the end of a Wave file. Now we only attempt to read up to the end of sample data, but no further. Also, added comments to clarify the meaning of "sample", and how it should be independent of the number of channels.
2021-06-10 17:59:00 +00:00
// AK::InputStream does not define seek, hence the special-cases for file and stream.
LibAudio: WavLoader: Avoid reading partial samples When samples are requested in `Audio::Loader::get_more_samples`, the request comes in as a max number of bytes to read. However, the requested number of bytes may not be an even multiple of the bytes per sample of the loaded file. If this is the case, and the bytes are read from the file/stream, then the last sample will be a partial/runt sample, which then offsets the remainder of the stream, causing white noise in playback. This bug was discovered when trying to play 24-bit Wave files, which happened to have a sample size that never aligned with the number of requested bytes. This commit fixes the bug by only reading a multiple of "bytes per sample" for the loaded file.
2021-06-05 17:14:03 +00:00
if (m_file) {
LibAudio: Avoid reading past the end of sample data Prior code in `WavLoader::get_more_samples()` would attempt to read the requested number of samples without actually checking whether that many samples were remaining in the stream. This was the cause of an audible pop at the end of a track, due to reading non-audio data that is sometimes at the end of a Wave file. Now we only attempt to read up to the end of sample data, but no further. Also, added comments to clarify the meaning of "sample", and how it should be independent of the number of channels.
2021-06-10 17:59:00 +00:00
m_file->seek(sample_offset);
LibAudio: WavLoader: Avoid reading partial samples When samples are requested in `Audio::Loader::get_more_samples`, the request comes in as a max number of bytes to read. However, the requested number of bytes may not be an even multiple of the bytes per sample of the loaded file. If this is the case, and the bytes are read from the file/stream, then the last sample will be a partial/runt sample, which then offsets the remainder of the stream, causing white noise in playback. This bug was discovered when trying to play 24-bit Wave files, which happened to have a sample size that never aligned with the number of requested bytes. This commit fixes the bug by only reading a multiple of "bytes per sample" for the loaded file.
2021-06-05 17:14:03 +00:00
} else {
LibAudio: Avoid reading past the end of sample data Prior code in `WavLoader::get_more_samples()` would attempt to read the requested number of samples without actually checking whether that many samples were remaining in the stream. This was the cause of an audible pop at the end of a track, due to reading non-audio data that is sometimes at the end of a Wave file. Now we only attempt to read up to the end of sample data, but no further. Also, added comments to clarify the meaning of "sample", and how it should be independent of the number of channels.
2021-06-10 17:59:00 +00:00
m_memory_stream->seek(sample_offset);
LibAudio: WavLoader: Avoid reading partial samples When samples are requested in `Audio::Loader::get_more_samples`, the request comes in as a max number of bytes to read. However, the requested number of bytes may not be an even multiple of the bytes per sample of the loaded file. If this is the case, and the bytes are read from the file/stream, then the last sample will be a partial/runt sample, which then offsets the remainder of the stream, causing white noise in playback. This bug was discovered when trying to play 24-bit Wave files, which happened to have a sample size that never aligned with the number of requested bytes. This commit fixes the bug by only reading a multiple of "bytes per sample" for the loaded file.
2021-06-05 17:14:03 +00:00
}
LibAudio: Avoid reading past the end of sample data Prior code in `WavLoader::get_more_samples()` would attempt to read the requested number of samples without actually checking whether that many samples were remaining in the stream. This was the cause of an audible pop at the end of a track, due to reading non-audio data that is sometimes at the end of a Wave file. Now we only attempt to read up to the end of sample data, but no further. Also, added comments to clarify the meaning of "sample", and how it should be independent of the number of channels.
2021-06-10 17:59:00 +00:00
m_loaded_samples = sample_index;
LibAudio: New error propagation API in Loader and Buffer Previously, a libc-like out-of-line error information was used in the loader and its plugins. Now, all functions that may fail to do their job return some sort of Result. The universally-used error type ist the new LoaderError, which can contain information about the general error category (such as file format, I/O, unimplemented features), an error description, and location information, such as file index or sample index. Additionally, the loader plugins try to do as little work as possible in their constructors. Right after being constructed, a user should call initialize() and check the errors returned from there. (This is done transparently by Loader itself.) If a constructor caused an error, the call to initialize should check and return it immediately. This opportunity was used to rework a lot of the internal error propagation in both loader classes, especially FlacLoader. Therefore, a couple of other refactorings may have sneaked in as well. The adoption of LibAudio users is minimal. Piano's adoption is not important, as the code will receive major refactoring in the near future anyways. SoundPlayer's adoption is also less important, as changes to refactor it are in the works as well. aplay's adoption is the best and may serve as an example for other users. It also includes new buffering behavior. Buffer also gets some attention, making it OOM-safe and thereby also propagating its errors to the user.
2021-11-27 16:00:19 +00:00
return {};
LibAudio: Added playback control features to audio server LibAudio now supports pausing playback, clearing the buffer queue, retrieving the played samples since the last clear and retrieving the currently playing shared buffer id
2019-11-04 18:39:17 +00:00
}
LibAudio: Add support for WAVE_FORMAT_EXTENSIBLE This enables support for playing float32 and float64 WAVE_FORMAT_EXTENSIBLE files. The PCM data format is encoded in the first two bytes of the SubFormat GUID inside of the WAVE_FORMAT_EXTENSIBLE `fmt` chunk. Also, fixed the RIFF header size check to allow up to maximum_wav_size (currently defined as 1 GiB). The RIFF header size is the size of the entire file, so it should be checked against the largest Wave size.
2021-06-06 00:23:27 +00:00
// Specification reference: http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/WAVE.html
LibAudio: New error propagation API in Loader and Buffer Previously, a libc-like out-of-line error information was used in the loader and its plugins. Now, all functions that may fail to do their job return some sort of Result. The universally-used error type ist the new LoaderError, which can contain information about the general error category (such as file format, I/O, unimplemented features), an error description, and location information, such as file index or sample index. Additionally, the loader plugins try to do as little work as possible in their constructors. Right after being constructed, a user should call initialize() and check the errors returned from there. (This is done transparently by Loader itself.) If a constructor caused an error, the call to initialize should check and return it immediately. This opportunity was used to rework a lot of the internal error propagation in both loader classes, especially FlacLoader. Therefore, a couple of other refactorings may have sneaked in as well. The adoption of LibAudio users is minimal. Piano's adoption is not important, as the code will receive major refactoring in the near future anyways. SoundPlayer's adoption is also less important, as changes to refactor it are in the works as well. aplay's adoption is the best and may serve as an example for other users. It also includes new buffering behavior. Buffer also gets some attention, making it OOM-safe and thereby also propagating its errors to the user.
2021-11-27 16:00:19 +00:00
MaybeLoaderError WavLoaderPlugin::parse_header()
AudioServer: Assorted infrastructure work * Add a LibAudio, and move WAV file parsing there (via AWavFile and AWavLoader) * Add CLocalSocket, and CSocket::connect() variant for local address types. We make some small use of this in WindowServer (as that's where we modelled it from), but don't get too invasive as this PR is already quite large, and the WS I/O is a bit carefully done * Add an AClientConnection which will eventually be used to talk to AudioServer (and make use of it in Piano, though right now it really doesn't do anything except connect, using our new CLocalSocket...)
2019-07-13 17:42:03 +00:00
{
LibAudio: WavLoader: Avoid reading partial samples When samples are requested in `Audio::Loader::get_more_samples`, the request comes in as a max number of bytes to read. However, the requested number of bytes may not be an even multiple of the bytes per sample of the loaded file. If this is the case, and the bytes are read from the file/stream, then the last sample will be a partial/runt sample, which then offsets the remainder of the stream, causing white noise in playback. This bug was discovered when trying to play 24-bit Wave files, which happened to have a sample size that never aligned with the number of requested bytes. This commit fixes the bug by only reading a multiple of "bytes per sample" for the loaded file.
2021-06-05 17:14:03 +00:00
if (!m_stream)
LibAudio: New error propagation API in Loader and Buffer Previously, a libc-like out-of-line error information was used in the loader and its plugins. Now, all functions that may fail to do their job return some sort of Result. The universally-used error type ist the new LoaderError, which can contain information about the general error category (such as file format, I/O, unimplemented features), an error description, and location information, such as file index or sample index. Additionally, the loader plugins try to do as little work as possible in their constructors. Right after being constructed, a user should call initialize() and check the errors returned from there. (This is done transparently by Loader itself.) If a constructor caused an error, the call to initialize should check and return it immediately. This opportunity was used to rework a lot of the internal error propagation in both loader classes, especially FlacLoader. Therefore, a couple of other refactorings may have sneaked in as well. The adoption of LibAudio users is minimal. Piano's adoption is not important, as the code will receive major refactoring in the near future anyways. SoundPlayer's adoption is also less important, as changes to refactor it are in the works as well. aplay's adoption is the best and may serve as an example for other users. It also includes new buffering behavior. Buffer also gets some attention, making it OOM-safe and thereby also propagating its errors to the user.
2021-11-27 16:00:19 +00:00
return LoaderError { LoaderError::Category::Internal, 0, "No stream" };
LibAudio+LibCore: Remove unnecessary IODeviceStreamReader.h IODeviceStreamReader isn't pulling its weight. It's essentially a subset of InputFileStream with only one user (WavLoader). This refactors WavLoader to use InputFileStream instead.
2021-06-05 16:38:43 +00:00
bool ok = true;
LibAudio: Make Loader::seek() treat its input as a sample index This fixes a bug where if you try to play a Wave file a second time (or loop with `aplay -l`), the second time will be pure noise. The function `Audio::Loader::seek` is meant to seek to a specific audio sample, e.g. seek(0) should go to the first audio sample. However, WavLoader was interpreting seek(0) as the beginning of the file or stream, which contains non-audio header data. This fixes the bug by capturing the byte offset of the start of the audio data, and offseting the raw file/stream seek by that amount.
2021-06-06 00:14:55 +00:00
size_t bytes_read = 0;
LibAudio: Allow loading sounds from memory The Loader and WavLoaderPlugin classes now have methods for loading from a ByteBuffer, in addition to streaming from disk.
2020-12-02 14:44:45 +00:00
auto read_u8 = [&]() -> u8 {
u8 value;
LibAudio: WavLoader: Avoid reading partial samples When samples are requested in `Audio::Loader::get_more_samples`, the request comes in as a max number of bytes to read. However, the requested number of bytes may not be an even multiple of the bytes per sample of the loaded file. If this is the case, and the bytes are read from the file/stream, then the last sample will be a partial/runt sample, which then offsets the remainder of the stream, causing white noise in playback. This bug was discovered when trying to play 24-bit Wave files, which happened to have a sample size that never aligned with the number of requested bytes. This commit fixes the bug by only reading a multiple of "bytes per sample" for the loaded file.
2021-06-05 17:14:03 +00:00
*m_stream >> value;
if (m_stream->handle_any_error())
LibAudio+LibCore: Remove unnecessary IODeviceStreamReader.h IODeviceStreamReader isn't pulling its weight. It's essentially a subset of InputFileStream with only one user (WavLoader). This refactors WavLoader to use InputFileStream instead.
2021-06-05 16:38:43 +00:00
ok = false;
LibAudio: Make Loader::seek() treat its input as a sample index This fixes a bug where if you try to play a Wave file a second time (or loop with `aplay -l`), the second time will be pure noise. The function `Audio::Loader::seek` is meant to seek to a specific audio sample, e.g. seek(0) should go to the first audio sample. However, WavLoader was interpreting seek(0) as the beginning of the file or stream, which contains non-audio header data. This fixes the bug by capturing the byte offset of the start of the audio data, and offseting the raw file/stream seek by that amount.
2021-06-06 00:14:55 +00:00
bytes_read += 1;
LibAudio: Allow loading sounds from memory The Loader and WavLoaderPlugin classes now have methods for loading from a ByteBuffer, in addition to streaming from disk.
2020-12-02 14:44:45 +00:00
return value;
};
auto read_u16 = [&]() -> u16 {
u16 value;
LibAudio: WavLoader: Avoid reading partial samples When samples are requested in `Audio::Loader::get_more_samples`, the request comes in as a max number of bytes to read. However, the requested number of bytes may not be an even multiple of the bytes per sample of the loaded file. If this is the case, and the bytes are read from the file/stream, then the last sample will be a partial/runt sample, which then offsets the remainder of the stream, causing white noise in playback. This bug was discovered when trying to play 24-bit Wave files, which happened to have a sample size that never aligned with the number of requested bytes. This commit fixes the bug by only reading a multiple of "bytes per sample" for the loaded file.
2021-06-05 17:14:03 +00:00
*m_stream >> value;
if (m_stream->handle_any_error())
LibAudio+LibCore: Remove unnecessary IODeviceStreamReader.h IODeviceStreamReader isn't pulling its weight. It's essentially a subset of InputFileStream with only one user (WavLoader). This refactors WavLoader to use InputFileStream instead.
2021-06-05 16:38:43 +00:00
ok = false;
LibAudio: Make Loader::seek() treat its input as a sample index This fixes a bug where if you try to play a Wave file a second time (or loop with `aplay -l`), the second time will be pure noise. The function `Audio::Loader::seek` is meant to seek to a specific audio sample, e.g. seek(0) should go to the first audio sample. However, WavLoader was interpreting seek(0) as the beginning of the file or stream, which contains non-audio header data. This fixes the bug by capturing the byte offset of the start of the audio data, and offseting the raw file/stream seek by that amount.
2021-06-06 00:14:55 +00:00
bytes_read += 2;
LibAudio: Allow loading sounds from memory The Loader and WavLoaderPlugin classes now have methods for loading from a ByteBuffer, in addition to streaming from disk.
2020-12-02 14:44:45 +00:00
return value;
};
auto read_u32 = [&]() -> u32 {
u32 value;
LibAudio: WavLoader: Avoid reading partial samples When samples are requested in `Audio::Loader::get_more_samples`, the request comes in as a max number of bytes to read. However, the requested number of bytes may not be an even multiple of the bytes per sample of the loaded file. If this is the case, and the bytes are read from the file/stream, then the last sample will be a partial/runt sample, which then offsets the remainder of the stream, causing white noise in playback. This bug was discovered when trying to play 24-bit Wave files, which happened to have a sample size that never aligned with the number of requested bytes. This commit fixes the bug by only reading a multiple of "bytes per sample" for the loaded file.
2021-06-05 17:14:03 +00:00
*m_stream >> value;
if (m_stream->handle_any_error())
LibAudio+LibCore: Remove unnecessary IODeviceStreamReader.h IODeviceStreamReader isn't pulling its weight. It's essentially a subset of InputFileStream with only one user (WavLoader). This refactors WavLoader to use InputFileStream instead.
2021-06-05 16:38:43 +00:00
ok = false;
LibAudio: Make Loader::seek() treat its input as a sample index This fixes a bug where if you try to play a Wave file a second time (or loop with `aplay -l`), the second time will be pure noise. The function `Audio::Loader::seek` is meant to seek to a specific audio sample, e.g. seek(0) should go to the first audio sample. However, WavLoader was interpreting seek(0) as the beginning of the file or stream, which contains non-audio header data. This fixes the bug by capturing the byte offset of the start of the audio data, and offseting the raw file/stream seek by that amount.
2021-06-06 00:14:55 +00:00
bytes_read += 4;
LibAudio: Allow loading sounds from memory The Loader and WavLoaderPlugin classes now have methods for loading from a ByteBuffer, in addition to streaming from disk.
2020-12-02 14:44:45 +00:00
return value;
};
LibAudio: New error propagation API in Loader and Buffer Previously, a libc-like out-of-line error information was used in the loader and its plugins. Now, all functions that may fail to do their job return some sort of Result. The universally-used error type ist the new LoaderError, which can contain information about the general error category (such as file format, I/O, unimplemented features), an error description, and location information, such as file index or sample index. Additionally, the loader plugins try to do as little work as possible in their constructors. Right after being constructed, a user should call initialize() and check the errors returned from there. (This is done transparently by Loader itself.) If a constructor caused an error, the call to initialize should check and return it immediately. This opportunity was used to rework a lot of the internal error propagation in both loader classes, especially FlacLoader. Therefore, a couple of other refactorings may have sneaked in as well. The adoption of LibAudio users is minimal. Piano's adoption is not important, as the code will receive major refactoring in the near future anyways. SoundPlayer's adoption is also less important, as changes to refactor it are in the works as well. aplay's adoption is the best and may serve as an example for other users. It also includes new buffering behavior. Buffer also gets some attention, making it OOM-safe and thereby also propagating its errors to the user.
2021-11-27 16:00:19 +00:00
#define CHECK_OK(category, msg) \
do { \
if (!ok) \
return LoaderError { category, String::formatted("Parsing failed: {}", msg) }; \
LibAudio: Support 32 and 64-bit float WAV files LibAudio's WavLoader plugin for loading WAV files now supports loading audio files with 32-bit float or 64-bit float samples. By supporting these new non-int sample formats, Audio::Buffer now stores the sample format (out of a list of supported formats) instead of the raw bit depth. (The bit depth is easily calculated with pcm_bits_per_sample)
2021-04-26 15:13:04 +00:00
} while (0)
AudioServer: Assorted infrastructure work * Add a LibAudio, and move WAV file parsing there (via AWavFile and AWavLoader) * Add CLocalSocket, and CSocket::connect() variant for local address types. We make some small use of this in WindowServer (as that's where we modelled it from), but don't get too invasive as this PR is already quite large, and the WS I/O is a bit carefully done * Add an AClientConnection which will eventually be used to talk to AudioServer (and make use of it in Piano, though right now it really doesn't do anything except connect, using our new CLocalSocket...)
2019-07-13 17:42:03 +00:00
LibAudio: Allow loading sounds from memory The Loader and WavLoaderPlugin classes now have methods for loading from a ByteBuffer, in addition to streaming from disk.
2020-12-02 14:44:45 +00:00
u32 riff = read_u32();
AudioServer: Assorted infrastructure work * Add a LibAudio, and move WAV file parsing there (via AWavFile and AWavLoader) * Add CLocalSocket, and CSocket::connect() variant for local address types. We make some small use of this in WindowServer (as that's where we modelled it from), but don't get too invasive as this PR is already quite large, and the WS I/O is a bit carefully done * Add an AClientConnection which will eventually be used to talk to AudioServer (and make use of it in Piano, though right now it really doesn't do anything except connect, using our new CLocalSocket...)
2019-07-13 17:42:03 +00:00
ok = ok && riff == 0x46464952; // "RIFF"
LibAudio: New error propagation API in Loader and Buffer Previously, a libc-like out-of-line error information was used in the loader and its plugins. Now, all functions that may fail to do their job return some sort of Result. The universally-used error type ist the new LoaderError, which can contain information about the general error category (such as file format, I/O, unimplemented features), an error description, and location information, such as file index or sample index. Additionally, the loader plugins try to do as little work as possible in their constructors. Right after being constructed, a user should call initialize() and check the errors returned from there. (This is done transparently by Loader itself.) If a constructor caused an error, the call to initialize should check and return it immediately. This opportunity was used to rework a lot of the internal error propagation in both loader classes, especially FlacLoader. Therefore, a couple of other refactorings may have sneaked in as well. The adoption of LibAudio users is minimal. Piano's adoption is not important, as the code will receive major refactoring in the near future anyways. SoundPlayer's adoption is also less important, as changes to refactor it are in the works as well. aplay's adoption is the best and may serve as an example for other users. It also includes new buffering behavior. Buffer also gets some attention, making it OOM-safe and thereby also propagating its errors to the user.
2021-11-27 16:00:19 +00:00
CHECK_OK(LoaderError::Category::Format, "RIFF header");
AudioServer: Assorted infrastructure work * Add a LibAudio, and move WAV file parsing there (via AWavFile and AWavLoader) * Add CLocalSocket, and CSocket::connect() variant for local address types. We make some small use of this in WindowServer (as that's where we modelled it from), but don't get too invasive as this PR is already quite large, and the WS I/O is a bit carefully done * Add an AClientConnection which will eventually be used to talk to AudioServer (and make use of it in Piano, though right now it really doesn't do anything except connect, using our new CLocalSocket...)
2019-07-13 17:42:03 +00:00
LibAudio: Allow loading sounds from memory The Loader and WavLoaderPlugin classes now have methods for loading from a ByteBuffer, in addition to streaming from disk.
2020-12-02 14:44:45 +00:00
u32 sz = read_u32();
LibAudio: Add support for WAVE_FORMAT_EXTENSIBLE This enables support for playing float32 and float64 WAVE_FORMAT_EXTENSIBLE files. The PCM data format is encoded in the first two bytes of the SubFormat GUID inside of the WAVE_FORMAT_EXTENSIBLE `fmt` chunk. Also, fixed the RIFF header size check to allow up to maximum_wav_size (currently defined as 1 GiB). The RIFF header size is the size of the entire file, so it should be checked against the largest Wave size.
2021-06-06 00:23:27 +00:00
ok = ok && sz < maximum_wav_size;
LibAudio: New error propagation API in Loader and Buffer Previously, a libc-like out-of-line error information was used in the loader and its plugins. Now, all functions that may fail to do their job return some sort of Result. The universally-used error type ist the new LoaderError, which can contain information about the general error category (such as file format, I/O, unimplemented features), an error description, and location information, such as file index or sample index. Additionally, the loader plugins try to do as little work as possible in their constructors. Right after being constructed, a user should call initialize() and check the errors returned from there. (This is done transparently by Loader itself.) If a constructor caused an error, the call to initialize should check and return it immediately. This opportunity was used to rework a lot of the internal error propagation in both loader classes, especially FlacLoader. Therefore, a couple of other refactorings may have sneaked in as well. The adoption of LibAudio users is minimal. Piano's adoption is not important, as the code will receive major refactoring in the near future anyways. SoundPlayer's adoption is also less important, as changes to refactor it are in the works as well. aplay's adoption is the best and may serve as an example for other users. It also includes new buffering behavior. Buffer also gets some attention, making it OOM-safe and thereby also propagating its errors to the user.
2021-11-27 16:00:19 +00:00
CHECK_OK(LoaderError::Category::Format, "File size");
AudioServer: Assorted infrastructure work * Add a LibAudio, and move WAV file parsing there (via AWavFile and AWavLoader) * Add CLocalSocket, and CSocket::connect() variant for local address types. We make some small use of this in WindowServer (as that's where we modelled it from), but don't get too invasive as this PR is already quite large, and the WS I/O is a bit carefully done * Add an AClientConnection which will eventually be used to talk to AudioServer (and make use of it in Piano, though right now it really doesn't do anything except connect, using our new CLocalSocket...)
2019-07-13 17:42:03 +00:00
LibAudio: Allow loading sounds from memory The Loader and WavLoaderPlugin classes now have methods for loading from a ByteBuffer, in addition to streaming from disk.
2020-12-02 14:44:45 +00:00
u32 wave = read_u32();
AudioServer: Assorted infrastructure work * Add a LibAudio, and move WAV file parsing there (via AWavFile and AWavLoader) * Add CLocalSocket, and CSocket::connect() variant for local address types. We make some small use of this in WindowServer (as that's where we modelled it from), but don't get too invasive as this PR is already quite large, and the WS I/O is a bit carefully done * Add an AClientConnection which will eventually be used to talk to AudioServer (and make use of it in Piano, though right now it really doesn't do anything except connect, using our new CLocalSocket...)
2019-07-13 17:42:03 +00:00
ok = ok && wave == 0x45564157; // "WAVE"
LibAudio: New error propagation API in Loader and Buffer Previously, a libc-like out-of-line error information was used in the loader and its plugins. Now, all functions that may fail to do their job return some sort of Result. The universally-used error type ist the new LoaderError, which can contain information about the general error category (such as file format, I/O, unimplemented features), an error description, and location information, such as file index or sample index. Additionally, the loader plugins try to do as little work as possible in their constructors. Right after being constructed, a user should call initialize() and check the errors returned from there. (This is done transparently by Loader itself.) If a constructor caused an error, the call to initialize should check and return it immediately. This opportunity was used to rework a lot of the internal error propagation in both loader classes, especially FlacLoader. Therefore, a couple of other refactorings may have sneaked in as well. The adoption of LibAudio users is minimal. Piano's adoption is not important, as the code will receive major refactoring in the near future anyways. SoundPlayer's adoption is also less important, as changes to refactor it are in the works as well. aplay's adoption is the best and may serve as an example for other users. It also includes new buffering behavior. Buffer also gets some attention, making it OOM-safe and thereby also propagating its errors to the user.
2021-11-27 16:00:19 +00:00
CHECK_OK(LoaderError::Category::Format, "WAVE header");
AudioServer: Assorted infrastructure work * Add a LibAudio, and move WAV file parsing there (via AWavFile and AWavLoader) * Add CLocalSocket, and CSocket::connect() variant for local address types. We make some small use of this in WindowServer (as that's where we modelled it from), but don't get too invasive as this PR is already quite large, and the WS I/O is a bit carefully done * Add an AClientConnection which will eventually be used to talk to AudioServer (and make use of it in Piano, though right now it really doesn't do anything except connect, using our new CLocalSocket...)
2019-07-13 17:42:03 +00:00
LibAudio: Allow loading sounds from memory The Loader and WavLoaderPlugin classes now have methods for loading from a ByteBuffer, in addition to streaming from disk.
2020-12-02 14:44:45 +00:00
u32 fmt_id = read_u32();
LibAudio: Add support for WAVE_FORMAT_EXTENSIBLE This enables support for playing float32 and float64 WAVE_FORMAT_EXTENSIBLE files. The PCM data format is encoded in the first two bytes of the SubFormat GUID inside of the WAVE_FORMAT_EXTENSIBLE `fmt` chunk. Also, fixed the RIFF header size check to allow up to maximum_wav_size (currently defined as 1 GiB). The RIFF header size is the size of the entire file, so it should be checked against the largest Wave size.
2021-06-06 00:23:27 +00:00
ok = ok && fmt_id == 0x20746D66; // "fmt "
LibAudio: New error propagation API in Loader and Buffer Previously, a libc-like out-of-line error information was used in the loader and its plugins. Now, all functions that may fail to do their job return some sort of Result. The universally-used error type ist the new LoaderError, which can contain information about the general error category (such as file format, I/O, unimplemented features), an error description, and location information, such as file index or sample index. Additionally, the loader plugins try to do as little work as possible in their constructors. Right after being constructed, a user should call initialize() and check the errors returned from there. (This is done transparently by Loader itself.) If a constructor caused an error, the call to initialize should check and return it immediately. This opportunity was used to rework a lot of the internal error propagation in both loader classes, especially FlacLoader. Therefore, a couple of other refactorings may have sneaked in as well. The adoption of LibAudio users is minimal. Piano's adoption is not important, as the code will receive major refactoring in the near future anyways. SoundPlayer's adoption is also less important, as changes to refactor it are in the works as well. aplay's adoption is the best and may serve as an example for other users. It also includes new buffering behavior. Buffer also gets some attention, making it OOM-safe and thereby also propagating its errors to the user.
2021-11-27 16:00:19 +00:00
CHECK_OK(LoaderError::Category::Format, "FMT header");
AudioServer: Assorted infrastructure work * Add a LibAudio, and move WAV file parsing there (via AWavFile and AWavLoader) * Add CLocalSocket, and CSocket::connect() variant for local address types. We make some small use of this in WindowServer (as that's where we modelled it from), but don't get too invasive as this PR is already quite large, and the WS I/O is a bit carefully done * Add an AClientConnection which will eventually be used to talk to AudioServer (and make use of it in Piano, though right now it really doesn't do anything except connect, using our new CLocalSocket...)
2019-07-13 17:42:03 +00:00
LibAudio: Allow loading sounds from memory The Loader and WavLoaderPlugin classes now have methods for loading from a ByteBuffer, in addition to streaming from disk.
2020-12-02 14:44:45 +00:00
u32 fmt_size = read_u32();
LibAudio: Add support for WAVE_FORMAT_EXTENSIBLE This enables support for playing float32 and float64 WAVE_FORMAT_EXTENSIBLE files. The PCM data format is encoded in the first two bytes of the SubFormat GUID inside of the WAVE_FORMAT_EXTENSIBLE `fmt` chunk. Also, fixed the RIFF header size check to allow up to maximum_wav_size (currently defined as 1 GiB). The RIFF header size is the size of the entire file, so it should be checked against the largest Wave size.
2021-06-06 00:23:27 +00:00
ok = ok && (fmt_size == 16 || fmt_size == 18 || fmt_size == 40);
LibAudio: New error propagation API in Loader and Buffer Previously, a libc-like out-of-line error information was used in the loader and its plugins. Now, all functions that may fail to do their job return some sort of Result. The universally-used error type ist the new LoaderError, which can contain information about the general error category (such as file format, I/O, unimplemented features), an error description, and location information, such as file index or sample index. Additionally, the loader plugins try to do as little work as possible in their constructors. Right after being constructed, a user should call initialize() and check the errors returned from there. (This is done transparently by Loader itself.) If a constructor caused an error, the call to initialize should check and return it immediately. This opportunity was used to rework a lot of the internal error propagation in both loader classes, especially FlacLoader. Therefore, a couple of other refactorings may have sneaked in as well. The adoption of LibAudio users is minimal. Piano's adoption is not important, as the code will receive major refactoring in the near future anyways. SoundPlayer's adoption is also less important, as changes to refactor it are in the works as well. aplay's adoption is the best and may serve as an example for other users. It also includes new buffering behavior. Buffer also gets some attention, making it OOM-safe and thereby also propagating its errors to the user.
2021-11-27 16:00:19 +00:00
CHECK_OK(LoaderError::Category::Format, "FMT size");
AudioServer: Assorted infrastructure work * Add a LibAudio, and move WAV file parsing there (via AWavFile and AWavLoader) * Add CLocalSocket, and CSocket::connect() variant for local address types. We make some small use of this in WindowServer (as that's where we modelled it from), but don't get too invasive as this PR is already quite large, and the WS I/O is a bit carefully done * Add an AClientConnection which will eventually be used to talk to AudioServer (and make use of it in Piano, though right now it really doesn't do anything except connect, using our new CLocalSocket...)
2019-07-13 17:42:03 +00:00
LibAudio: Allow loading sounds from memory The Loader and WavLoaderPlugin classes now have methods for loading from a ByteBuffer, in addition to streaming from disk.
2020-12-02 14:44:45 +00:00
u16 audio_format = read_u16();
LibAudio: New error propagation API in Loader and Buffer Previously, a libc-like out-of-line error information was used in the loader and its plugins. Now, all functions that may fail to do their job return some sort of Result. The universally-used error type ist the new LoaderError, which can contain information about the general error category (such as file format, I/O, unimplemented features), an error description, and location information, such as file index or sample index. Additionally, the loader plugins try to do as little work as possible in their constructors. Right after being constructed, a user should call initialize() and check the errors returned from there. (This is done transparently by Loader itself.) If a constructor caused an error, the call to initialize should check and return it immediately. This opportunity was used to rework a lot of the internal error propagation in both loader classes, especially FlacLoader. Therefore, a couple of other refactorings may have sneaked in as well. The adoption of LibAudio users is minimal. Piano's adoption is not important, as the code will receive major refactoring in the near future anyways. SoundPlayer's adoption is also less important, as changes to refactor it are in the works as well. aplay's adoption is the best and may serve as an example for other users. It also includes new buffering behavior. Buffer also gets some attention, making it OOM-safe and thereby also propagating its errors to the user.
2021-11-27 16:00:19 +00:00
CHECK_OK(LoaderError::Category::Format, "Audio format"); // incomplete read check
LibAudio: Add support for WAVE_FORMAT_EXTENSIBLE This enables support for playing float32 and float64 WAVE_FORMAT_EXTENSIBLE files. The PCM data format is encoded in the first two bytes of the SubFormat GUID inside of the WAVE_FORMAT_EXTENSIBLE `fmt` chunk. Also, fixed the RIFF header size check to allow up to maximum_wav_size (currently defined as 1 GiB). The RIFF header size is the size of the entire file, so it should be checked against the largest Wave size.
2021-06-06 00:23:27 +00:00
ok = ok && (audio_format == WAVE_FORMAT_PCM || audio_format == WAVE_FORMAT_IEEE_FLOAT || audio_format == WAVE_FORMAT_EXTENSIBLE);
LibAudio: New error propagation API in Loader and Buffer Previously, a libc-like out-of-line error information was used in the loader and its plugins. Now, all functions that may fail to do their job return some sort of Result. The universally-used error type ist the new LoaderError, which can contain information about the general error category (such as file format, I/O, unimplemented features), an error description, and location information, such as file index or sample index. Additionally, the loader plugins try to do as little work as possible in their constructors. Right after being constructed, a user should call initialize() and check the errors returned from there. (This is done transparently by Loader itself.) If a constructor caused an error, the call to initialize should check and return it immediately. This opportunity was used to rework a lot of the internal error propagation in both loader classes, especially FlacLoader. Therefore, a couple of other refactorings may have sneaked in as well. The adoption of LibAudio users is minimal. Piano's adoption is not important, as the code will receive major refactoring in the near future anyways. SoundPlayer's adoption is also less important, as changes to refactor it are in the works as well. aplay's adoption is the best and may serve as an example for other users. It also includes new buffering behavior. Buffer also gets some attention, making it OOM-safe and thereby also propagating its errors to the user.
2021-11-27 16:00:19 +00:00
CHECK_OK(LoaderError::Category::Unimplemented, "Audio format PCM/Float"); // value check
AudioServer: Assorted infrastructure work * Add a LibAudio, and move WAV file parsing there (via AWavFile and AWavLoader) * Add CLocalSocket, and CSocket::connect() variant for local address types. We make some small use of this in WindowServer (as that's where we modelled it from), but don't get too invasive as this PR is already quite large, and the WS I/O is a bit carefully done * Add an AClientConnection which will eventually be used to talk to AudioServer (and make use of it in Piano, though right now it really doesn't do anything except connect, using our new CLocalSocket...)
2019-07-13 17:42:03 +00:00
LibAudio: Allow loading sounds from memory The Loader and WavLoaderPlugin classes now have methods for loading from a ByteBuffer, in addition to streaming from disk.
2020-12-02 14:44:45 +00:00
m_num_channels = read_u16();
Audio: Make basic streaming WAV playback work. I had to solve a bunch of things simultaneously to make this work. Refactor AWavLoader to be a streaming loader rather than a one-shot one. The constructor parses the header, and if everything looks good, you can repeatedly ask the AWavLoader for sample buffers until it runs out. Also send a message from AudioServer when a buffer has finished playing. That allows us to implement a blocking variant of play(). Use all of this in aplay to play WAV files chunk-at-a-time. This is definitely not perfect and it's a little glitchy and skippy, but I think it's a step in the right direction.
2019-07-27 15:20:41 +00:00
ok = ok && (m_num_channels == 1 || m_num_channels == 2);
LibAudio: New error propagation API in Loader and Buffer Previously, a libc-like out-of-line error information was used in the loader and its plugins. Now, all functions that may fail to do their job return some sort of Result. The universally-used error type ist the new LoaderError, which can contain information about the general error category (such as file format, I/O, unimplemented features), an error description, and location information, such as file index or sample index. Additionally, the loader plugins try to do as little work as possible in their constructors. Right after being constructed, a user should call initialize() and check the errors returned from there. (This is done transparently by Loader itself.) If a constructor caused an error, the call to initialize should check and return it immediately. This opportunity was used to rework a lot of the internal error propagation in both loader classes, especially FlacLoader. Therefore, a couple of other refactorings may have sneaked in as well. The adoption of LibAudio users is minimal. Piano's adoption is not important, as the code will receive major refactoring in the near future anyways. SoundPlayer's adoption is also less important, as changes to refactor it are in the works as well. aplay's adoption is the best and may serve as an example for other users. It also includes new buffering behavior. Buffer also gets some attention, making it OOM-safe and thereby also propagating its errors to the user.
2021-11-27 16:00:19 +00:00
CHECK_OK(LoaderError::Category::Unimplemented, "Channel count");
AudioServer: Assorted infrastructure work * Add a LibAudio, and move WAV file parsing there (via AWavFile and AWavLoader) * Add CLocalSocket, and CSocket::connect() variant for local address types. We make some small use of this in WindowServer (as that's where we modelled it from), but don't get too invasive as this PR is already quite large, and the WS I/O is a bit carefully done * Add an AClientConnection which will eventually be used to talk to AudioServer (and make use of it in Piano, though right now it really doesn't do anything except connect, using our new CLocalSocket...)
2019-07-13 17:42:03 +00:00
LibAudio: Allow loading sounds from memory The Loader and WavLoaderPlugin classes now have methods for loading from a ByteBuffer, in addition to streaming from disk.
2020-12-02 14:44:45 +00:00
m_sample_rate = read_u32();
LibAudio: New error propagation API in Loader and Buffer Previously, a libc-like out-of-line error information was used in the loader and its plugins. Now, all functions that may fail to do their job return some sort of Result. The universally-used error type ist the new LoaderError, which can contain information about the general error category (such as file format, I/O, unimplemented features), an error description, and location information, such as file index or sample index. Additionally, the loader plugins try to do as little work as possible in their constructors. Right after being constructed, a user should call initialize() and check the errors returned from there. (This is done transparently by Loader itself.) If a constructor caused an error, the call to initialize should check and return it immediately. This opportunity was used to rework a lot of the internal error propagation in both loader classes, especially FlacLoader. Therefore, a couple of other refactorings may have sneaked in as well. The adoption of LibAudio users is minimal. Piano's adoption is not important, as the code will receive major refactoring in the near future anyways. SoundPlayer's adoption is also less important, as changes to refactor it are in the works as well. aplay's adoption is the best and may serve as an example for other users. It also includes new buffering behavior. Buffer also gets some attention, making it OOM-safe and thereby also propagating its errors to the user.
2021-11-27 16:00:19 +00:00
CHECK_OK(LoaderError::Category::IO, "Sample rate");
AudioServer: Assorted infrastructure work * Add a LibAudio, and move WAV file parsing there (via AWavFile and AWavLoader) * Add CLocalSocket, and CSocket::connect() variant for local address types. We make some small use of this in WindowServer (as that's where we modelled it from), but don't get too invasive as this PR is already quite large, and the WS I/O is a bit carefully done * Add an AClientConnection which will eventually be used to talk to AudioServer (and make use of it in Piano, though right now it really doesn't do anything except connect, using our new CLocalSocket...)
2019-07-13 17:42:03 +00:00
LibAudio: Allow loading sounds from memory The Loader and WavLoaderPlugin classes now have methods for loading from a ByteBuffer, in addition to streaming from disk.
2020-12-02 14:44:45 +00:00
read_u32();
LibAudio: New error propagation API in Loader and Buffer Previously, a libc-like out-of-line error information was used in the loader and its plugins. Now, all functions that may fail to do their job return some sort of Result. The universally-used error type ist the new LoaderError, which can contain information about the general error category (such as file format, I/O, unimplemented features), an error description, and location information, such as file index or sample index. Additionally, the loader plugins try to do as little work as possible in their constructors. Right after being constructed, a user should call initialize() and check the errors returned from there. (This is done transparently by Loader itself.) If a constructor caused an error, the call to initialize should check and return it immediately. This opportunity was used to rework a lot of the internal error propagation in both loader classes, especially FlacLoader. Therefore, a couple of other refactorings may have sneaked in as well. The adoption of LibAudio users is minimal. Piano's adoption is not important, as the code will receive major refactoring in the near future anyways. SoundPlayer's adoption is also less important, as changes to refactor it are in the works as well. aplay's adoption is the best and may serve as an example for other users. It also includes new buffering behavior. Buffer also gets some attention, making it OOM-safe and thereby also propagating its errors to the user.
2021-11-27 16:00:19 +00:00
CHECK_OK(LoaderError::Category::IO, "Data rate");
AudioServer: Assorted infrastructure work * Add a LibAudio, and move WAV file parsing there (via AWavFile and AWavLoader) * Add CLocalSocket, and CSocket::connect() variant for local address types. We make some small use of this in WindowServer (as that's where we modelled it from), but don't get too invasive as this PR is already quite large, and the WS I/O is a bit carefully done * Add an AClientConnection which will eventually be used to talk to AudioServer (and make use of it in Piano, though right now it really doesn't do anything except connect, using our new CLocalSocket...)
2019-07-13 17:42:03 +00:00
LibAudio: Avoid reading past the end of sample data Prior code in `WavLoader::get_more_samples()` would attempt to read the requested number of samples without actually checking whether that many samples were remaining in the stream. This was the cause of an audible pop at the end of a track, due to reading non-audio data that is sometimes at the end of a Wave file. Now we only attempt to read up to the end of sample data, but no further. Also, added comments to clarify the meaning of "sample", and how it should be independent of the number of channels.
2021-06-10 17:59:00 +00:00
u16 block_size_bytes = read_u16();
LibAudio: New error propagation API in Loader and Buffer Previously, a libc-like out-of-line error information was used in the loader and its plugins. Now, all functions that may fail to do their job return some sort of Result. The universally-used error type ist the new LoaderError, which can contain information about the general error category (such as file format, I/O, unimplemented features), an error description, and location information, such as file index or sample index. Additionally, the loader plugins try to do as little work as possible in their constructors. Right after being constructed, a user should call initialize() and check the errors returned from there. (This is done transparently by Loader itself.) If a constructor caused an error, the call to initialize should check and return it immediately. This opportunity was used to rework a lot of the internal error propagation in both loader classes, especially FlacLoader. Therefore, a couple of other refactorings may have sneaked in as well. The adoption of LibAudio users is minimal. Piano's adoption is not important, as the code will receive major refactoring in the near future anyways. SoundPlayer's adoption is also less important, as changes to refactor it are in the works as well. aplay's adoption is the best and may serve as an example for other users. It also includes new buffering behavior. Buffer also gets some attention, making it OOM-safe and thereby also propagating its errors to the user.
2021-11-27 16:00:19 +00:00
CHECK_OK(LoaderError::Category::IO, "Block size");
AudioServer: Assorted infrastructure work * Add a LibAudio, and move WAV file parsing there (via AWavFile and AWavLoader) * Add CLocalSocket, and CSocket::connect() variant for local address types. We make some small use of this in WindowServer (as that's where we modelled it from), but don't get too invasive as this PR is already quite large, and the WS I/O is a bit carefully done * Add an AClientConnection which will eventually be used to talk to AudioServer (and make use of it in Piano, though right now it really doesn't do anything except connect, using our new CLocalSocket...)
2019-07-13 17:42:03 +00:00
LibAudio: Support 32 and 64-bit float WAV files LibAudio's WavLoader plugin for loading WAV files now supports loading audio files with 32-bit float or 64-bit float samples. By supporting these new non-int sample formats, Audio::Buffer now stores the sample format (out of a list of supported formats) instead of the raw bit depth. (The bit depth is easily calculated with pcm_bits_per_sample)
2021-04-26 15:13:04 +00:00
u16 bits_per_sample = read_u16();
LibAudio: New error propagation API in Loader and Buffer Previously, a libc-like out-of-line error information was used in the loader and its plugins. Now, all functions that may fail to do their job return some sort of Result. The universally-used error type ist the new LoaderError, which can contain information about the general error category (such as file format, I/O, unimplemented features), an error description, and location information, such as file index or sample index. Additionally, the loader plugins try to do as little work as possible in their constructors. Right after being constructed, a user should call initialize() and check the errors returned from there. (This is done transparently by Loader itself.) If a constructor caused an error, the call to initialize should check and return it immediately. This opportunity was used to rework a lot of the internal error propagation in both loader classes, especially FlacLoader. Therefore, a couple of other refactorings may have sneaked in as well. The adoption of LibAudio users is minimal. Piano's adoption is not important, as the code will receive major refactoring in the near future anyways. SoundPlayer's adoption is also less important, as changes to refactor it are in the works as well. aplay's adoption is the best and may serve as an example for other users. It also includes new buffering behavior. Buffer also gets some attention, making it OOM-safe and thereby also propagating its errors to the user.
2021-11-27 16:00:19 +00:00
CHECK_OK(LoaderError::Category::IO, "Bits per sample");
LibAudio: Add support for WAVE_FORMAT_EXTENSIBLE This enables support for playing float32 and float64 WAVE_FORMAT_EXTENSIBLE files. The PCM data format is encoded in the first two bytes of the SubFormat GUID inside of the WAVE_FORMAT_EXTENSIBLE `fmt` chunk. Also, fixed the RIFF header size check to allow up to maximum_wav_size (currently defined as 1 GiB). The RIFF header size is the size of the entire file, so it should be checked against the largest Wave size.
2021-06-06 00:23:27 +00:00
if (audio_format == WAVE_FORMAT_EXTENSIBLE) {
ok = ok && (fmt_size == 40);
LibAudio: New error propagation API in Loader and Buffer Previously, a libc-like out-of-line error information was used in the loader and its plugins. Now, all functions that may fail to do their job return some sort of Result. The universally-used error type ist the new LoaderError, which can contain information about the general error category (such as file format, I/O, unimplemented features), an error description, and location information, such as file index or sample index. Additionally, the loader plugins try to do as little work as possible in their constructors. Right after being constructed, a user should call initialize() and check the errors returned from there. (This is done transparently by Loader itself.) If a constructor caused an error, the call to initialize should check and return it immediately. This opportunity was used to rework a lot of the internal error propagation in both loader classes, especially FlacLoader. Therefore, a couple of other refactorings may have sneaked in as well. The adoption of LibAudio users is minimal. Piano's adoption is not important, as the code will receive major refactoring in the near future anyways. SoundPlayer's adoption is also less important, as changes to refactor it are in the works as well. aplay's adoption is the best and may serve as an example for other users. It also includes new buffering behavior. Buffer also gets some attention, making it OOM-safe and thereby also propagating its errors to the user.
2021-11-27 16:00:19 +00:00
CHECK_OK(LoaderError::Category::Format, "Extensible fmt size"); // value check
LibAudio: Add support for WAVE_FORMAT_EXTENSIBLE This enables support for playing float32 and float64 WAVE_FORMAT_EXTENSIBLE files. The PCM data format is encoded in the first two bytes of the SubFormat GUID inside of the WAVE_FORMAT_EXTENSIBLE `fmt` chunk. Also, fixed the RIFF header size check to allow up to maximum_wav_size (currently defined as 1 GiB). The RIFF header size is the size of the entire file, so it should be checked against the largest Wave size.
2021-06-06 00:23:27 +00:00
// Discard everything until the GUID.
// We've already read 16 bytes from the stream. The GUID starts in another 8 bytes.
read_u32();
read_u32();
LibAudio: New error propagation API in Loader and Buffer Previously, a libc-like out-of-line error information was used in the loader and its plugins. Now, all functions that may fail to do their job return some sort of Result. The universally-used error type ist the new LoaderError, which can contain information about the general error category (such as file format, I/O, unimplemented features), an error description, and location information, such as file index or sample index. Additionally, the loader plugins try to do as little work as possible in their constructors. Right after being constructed, a user should call initialize() and check the errors returned from there. (This is done transparently by Loader itself.) If a constructor caused an error, the call to initialize should check and return it immediately. This opportunity was used to rework a lot of the internal error propagation in both loader classes, especially FlacLoader. Therefore, a couple of other refactorings may have sneaked in as well. The adoption of LibAudio users is minimal. Piano's adoption is not important, as the code will receive major refactoring in the near future anyways. SoundPlayer's adoption is also less important, as changes to refactor it are in the works as well. aplay's adoption is the best and may serve as an example for other users. It also includes new buffering behavior. Buffer also gets some attention, making it OOM-safe and thereby also propagating its errors to the user.
2021-11-27 16:00:19 +00:00
CHECK_OK(LoaderError::Category::IO, "Discard until GUID");
LibAudio: Add support for WAVE_FORMAT_EXTENSIBLE This enables support for playing float32 and float64 WAVE_FORMAT_EXTENSIBLE files. The PCM data format is encoded in the first two bytes of the SubFormat GUID inside of the WAVE_FORMAT_EXTENSIBLE `fmt` chunk. Also, fixed the RIFF header size check to allow up to maximum_wav_size (currently defined as 1 GiB). The RIFF header size is the size of the entire file, so it should be checked against the largest Wave size.
2021-06-06 00:23:27 +00:00
// Get the underlying audio format from the first two bytes of GUID
u16 guid_subformat = read_u16();
ok = ok && (guid_subformat == WAVE_FORMAT_PCM || guid_subformat == WAVE_FORMAT_IEEE_FLOAT);
LibAudio: New error propagation API in Loader and Buffer Previously, a libc-like out-of-line error information was used in the loader and its plugins. Now, all functions that may fail to do their job return some sort of Result. The universally-used error type ist the new LoaderError, which can contain information about the general error category (such as file format, I/O, unimplemented features), an error description, and location information, such as file index or sample index. Additionally, the loader plugins try to do as little work as possible in their constructors. Right after being constructed, a user should call initialize() and check the errors returned from there. (This is done transparently by Loader itself.) If a constructor caused an error, the call to initialize should check and return it immediately. This opportunity was used to rework a lot of the internal error propagation in both loader classes, especially FlacLoader. Therefore, a couple of other refactorings may have sneaked in as well. The adoption of LibAudio users is minimal. Piano's adoption is not important, as the code will receive major refactoring in the near future anyways. SoundPlayer's adoption is also less important, as changes to refactor it are in the works as well. aplay's adoption is the best and may serve as an example for other users. It also includes new buffering behavior. Buffer also gets some attention, making it OOM-safe and thereby also propagating its errors to the user.
2021-11-27 16:00:19 +00:00
CHECK_OK(LoaderError::Category::Unimplemented, "GUID SubFormat");
LibAudio: Add support for WAVE_FORMAT_EXTENSIBLE This enables support for playing float32 and float64 WAVE_FORMAT_EXTENSIBLE files. The PCM data format is encoded in the first two bytes of the SubFormat GUID inside of the WAVE_FORMAT_EXTENSIBLE `fmt` chunk. Also, fixed the RIFF header size check to allow up to maximum_wav_size (currently defined as 1 GiB). The RIFF header size is the size of the entire file, so it should be checked against the largest Wave size.
2021-06-06 00:23:27 +00:00
audio_format = guid_subformat;
}
LibAudio: Support 32 and 64-bit float WAV files LibAudio's WavLoader plugin for loading WAV files now supports loading audio files with 32-bit float or 64-bit float samples. By supporting these new non-int sample formats, Audio::Buffer now stores the sample format (out of a list of supported formats) instead of the raw bit depth. (The bit depth is easily calculated with pcm_bits_per_sample)
2021-04-26 15:13:04 +00:00
if (audio_format == WAVE_FORMAT_PCM) {
ok = ok && (bits_per_sample == 8 || bits_per_sample == 16 || bits_per_sample == 24);
LibAudio: New error propagation API in Loader and Buffer Previously, a libc-like out-of-line error information was used in the loader and its plugins. Now, all functions that may fail to do their job return some sort of Result. The universally-used error type ist the new LoaderError, which can contain information about the general error category (such as file format, I/O, unimplemented features), an error description, and location information, such as file index or sample index. Additionally, the loader plugins try to do as little work as possible in their constructors. Right after being constructed, a user should call initialize() and check the errors returned from there. (This is done transparently by Loader itself.) If a constructor caused an error, the call to initialize should check and return it immediately. This opportunity was used to rework a lot of the internal error propagation in both loader classes, especially FlacLoader. Therefore, a couple of other refactorings may have sneaked in as well. The adoption of LibAudio users is minimal. Piano's adoption is not important, as the code will receive major refactoring in the near future anyways. SoundPlayer's adoption is also less important, as changes to refactor it are in the works as well. aplay's adoption is the best and may serve as an example for other users. It also includes new buffering behavior. Buffer also gets some attention, making it OOM-safe and thereby also propagating its errors to the user.
2021-11-27 16:00:19 +00:00
CHECK_OK(LoaderError::Category::Unimplemented, "Bits per sample (PCM)"); // value check
LibAudio: Support 32 and 64-bit float WAV files LibAudio's WavLoader plugin for loading WAV files now supports loading audio files with 32-bit float or 64-bit float samples. By supporting these new non-int sample formats, Audio::Buffer now stores the sample format (out of a list of supported formats) instead of the raw bit depth. (The bit depth is easily calculated with pcm_bits_per_sample)
2021-04-26 15:13:04 +00:00
// We only support 8-24 bit audio right now because other formats are uncommon
if (bits_per_sample == 8) {
m_sample_format = PcmSampleFormat::Uint8;
} else if (bits_per_sample == 16) {
m_sample_format = PcmSampleFormat::Int16;
} else if (bits_per_sample == 24) {
m_sample_format = PcmSampleFormat::Int24;
}
} else if (audio_format == WAVE_FORMAT_IEEE_FLOAT) {
ok = ok && (bits_per_sample == 32 || bits_per_sample == 64);
LibAudio: New error propagation API in Loader and Buffer Previously, a libc-like out-of-line error information was used in the loader and its plugins. Now, all functions that may fail to do their job return some sort of Result. The universally-used error type ist the new LoaderError, which can contain information about the general error category (such as file format, I/O, unimplemented features), an error description, and location information, such as file index or sample index. Additionally, the loader plugins try to do as little work as possible in their constructors. Right after being constructed, a user should call initialize() and check the errors returned from there. (This is done transparently by Loader itself.) If a constructor caused an error, the call to initialize should check and return it immediately. This opportunity was used to rework a lot of the internal error propagation in both loader classes, especially FlacLoader. Therefore, a couple of other refactorings may have sneaked in as well. The adoption of LibAudio users is minimal. Piano's adoption is not important, as the code will receive major refactoring in the near future anyways. SoundPlayer's adoption is also less important, as changes to refactor it are in the works as well. aplay's adoption is the best and may serve as an example for other users. It also includes new buffering behavior. Buffer also gets some attention, making it OOM-safe and thereby also propagating its errors to the user.
2021-11-27 16:00:19 +00:00
CHECK_OK(LoaderError::Category::Unimplemented, "Bits per sample (Float)"); // value check
LibAudio: Support 32 and 64-bit float WAV files LibAudio's WavLoader plugin for loading WAV files now supports loading audio files with 32-bit float or 64-bit float samples. By supporting these new non-int sample formats, Audio::Buffer now stores the sample format (out of a list of supported formats) instead of the raw bit depth. (The bit depth is easily calculated with pcm_bits_per_sample)
2021-04-26 15:13:04 +00:00
// Again, only the common 32 and 64 bit
if (bits_per_sample == 32) {
m_sample_format = PcmSampleFormat::Float32;
} else if (bits_per_sample == 64) {
m_sample_format = PcmSampleFormat::Float64;
}
}
LibAudio: Avoid reading past the end of sample data Prior code in `WavLoader::get_more_samples()` would attempt to read the requested number of samples without actually checking whether that many samples were remaining in the stream. This was the cause of an audible pop at the end of a track, due to reading non-audio data that is sometimes at the end of a Wave file. Now we only attempt to read up to the end of sample data, but no further. Also, added comments to clarify the meaning of "sample", and how it should be independent of the number of channels.
2021-06-10 17:59:00 +00:00
ok = ok && (block_size_bytes == (m_num_channels * (bits_per_sample / 8)));
LibAudio: New error propagation API in Loader and Buffer Previously, a libc-like out-of-line error information was used in the loader and its plugins. Now, all functions that may fail to do their job return some sort of Result. The universally-used error type ist the new LoaderError, which can contain information about the general error category (such as file format, I/O, unimplemented features), an error description, and location information, such as file index or sample index. Additionally, the loader plugins try to do as little work as possible in their constructors. Right after being constructed, a user should call initialize() and check the errors returned from there. (This is done transparently by Loader itself.) If a constructor caused an error, the call to initialize should check and return it immediately. This opportunity was used to rework a lot of the internal error propagation in both loader classes, especially FlacLoader. Therefore, a couple of other refactorings may have sneaked in as well. The adoption of LibAudio users is minimal. Piano's adoption is not important, as the code will receive major refactoring in the near future anyways. SoundPlayer's adoption is also less important, as changes to refactor it are in the works as well. aplay's adoption is the best and may serve as an example for other users. It also includes new buffering behavior. Buffer also gets some attention, making it OOM-safe and thereby also propagating its errors to the user.
2021-11-27 16:00:19 +00:00
CHECK_OK(LoaderError::Category::Format, "Block size sanity check");
LibAudio: Avoid reading past the end of sample data Prior code in `WavLoader::get_more_samples()` would attempt to read the requested number of samples without actually checking whether that many samples were remaining in the stream. This was the cause of an audible pop at the end of a track, due to reading non-audio data that is sometimes at the end of a Wave file. Now we only attempt to read up to the end of sample data, but no further. Also, added comments to clarify the meaning of "sample", and how it should be independent of the number of channels.
2021-06-10 17:59:00 +00:00
Everywhere: Turn #if *_DEBUG into dbgln_if/if constexpr
2021-05-01 19:10:08 +00:00
dbgln_if(AWAVLOADER_DEBUG, "WAV format {} at {} bit, {} channels, rate {}Hz ",
sample_format_name(m_sample_format), pcm_bits_per_sample(m_sample_format), m_num_channels, m_sample_rate);
AudioServer: Assorted infrastructure work * Add a LibAudio, and move WAV file parsing there (via AWavFile and AWavLoader) * Add CLocalSocket, and CSocket::connect() variant for local address types. We make some small use of this in WindowServer (as that's where we modelled it from), but don't get too invasive as this PR is already quite large, and the WS I/O is a bit carefully done * Add an AClientConnection which will eventually be used to talk to AudioServer (and make use of it in Piano, though right now it really doesn't do anything except connect, using our new CLocalSocket...)
2019-07-13 17:42:03 +00:00
// Read chunks until we find DATA
bool found_data = false;
u32 data_sz = 0;
WavLoader: Search for DATA marker by reading single bytes Previously 4 bytes at once were read and compared to the string "DATA". This worked when the DATA marker was aligned on a 32-bit boundary relative to the start of the file. However, this is not guranteed to always be the case, and for some files the loader would just keep searching for the marker.
2020-06-18 18:00:32 +00:00
u8 search_byte = 0;
AK/LibAudio: Add stream read operators to AK::BufferStream, and use it in AWavLoader At the same time, we allow chaining of streaming operators, and add a way to check for partial reads (also used in WAV parsing).
2019-07-13 22:28:30 +00:00
while (true) {
LibAudio: Allow loading sounds from memory The Loader and WavLoaderPlugin classes now have methods for loading from a ByteBuffer, in addition to streaming from disk.
2020-12-02 14:44:45 +00:00
search_byte = read_u8();
LibAudio: New error propagation API in Loader and Buffer Previously, a libc-like out-of-line error information was used in the loader and its plugins. Now, all functions that may fail to do their job return some sort of Result. The universally-used error type ist the new LoaderError, which can contain information about the general error category (such as file format, I/O, unimplemented features), an error description, and location information, such as file index or sample index. Additionally, the loader plugins try to do as little work as possible in their constructors. Right after being constructed, a user should call initialize() and check the errors returned from there. (This is done transparently by Loader itself.) If a constructor caused an error, the call to initialize should check and return it immediately. This opportunity was used to rework a lot of the internal error propagation in both loader classes, especially FlacLoader. Therefore, a couple of other refactorings may have sneaked in as well. The adoption of LibAudio users is minimal. Piano's adoption is not important, as the code will receive major refactoring in the near future anyways. SoundPlayer's adoption is also less important, as changes to refactor it are in the works as well. aplay's adoption is the best and may serve as an example for other users. It also includes new buffering behavior. Buffer also gets some attention, making it OOM-safe and thereby also propagating its errors to the user.
2021-11-27 16:00:19 +00:00
CHECK_OK(LoaderError::Category::IO, "Reading byte searching for data");
Everywhere: Make ByteBuffer::{create_*,copy}() OOM-safe
2021-09-05 22:59:52 +00:00
if (search_byte != 0x64) // D
WavLoader: Search for DATA marker by reading single bytes Previously 4 bytes at once were read and compared to the string "DATA". This worked when the DATA marker was aligned on a 32-bit boundary relative to the start of the file. However, this is not guranteed to always be the case, and for some files the loader would just keep searching for the marker.
2020-06-18 18:00:32 +00:00
continue;
LibAudio: Allow loading sounds from memory The Loader and WavLoaderPlugin classes now have methods for loading from a ByteBuffer, in addition to streaming from disk.
2020-12-02 14:44:45 +00:00
search_byte = read_u8();
LibAudio: New error propagation API in Loader and Buffer Previously, a libc-like out-of-line error information was used in the loader and its plugins. Now, all functions that may fail to do their job return some sort of Result. The universally-used error type ist the new LoaderError, which can contain information about the general error category (such as file format, I/O, unimplemented features), an error description, and location information, such as file index or sample index. Additionally, the loader plugins try to do as little work as possible in their constructors. Right after being constructed, a user should call initialize() and check the errors returned from there. (This is done transparently by Loader itself.) If a constructor caused an error, the call to initialize should check and return it immediately. This opportunity was used to rework a lot of the internal error propagation in both loader classes, especially FlacLoader. Therefore, a couple of other refactorings may have sneaked in as well. The adoption of LibAudio users is minimal. Piano's adoption is not important, as the code will receive major refactoring in the near future anyways. SoundPlayer's adoption is also less important, as changes to refactor it are in the works as well. aplay's adoption is the best and may serve as an example for other users. It also includes new buffering behavior. Buffer also gets some attention, making it OOM-safe and thereby also propagating its errors to the user.
2021-11-27 16:00:19 +00:00
CHECK_OK(LoaderError::Category::IO, "Reading next byte searching for data");
Everywhere: Make ByteBuffer::{create_*,copy}() OOM-safe
2021-09-05 22:59:52 +00:00
if (search_byte != 0x61) // A
WavLoader: Search for DATA marker by reading single bytes Previously 4 bytes at once were read and compared to the string "DATA". This worked when the DATA marker was aligned on a 32-bit boundary relative to the start of the file. However, this is not guranteed to always be the case, and for some files the loader would just keep searching for the marker.
2020-06-18 18:00:32 +00:00
continue;
LibAudio: Allow loading sounds from memory The Loader and WavLoaderPlugin classes now have methods for loading from a ByteBuffer, in addition to streaming from disk.
2020-12-02 14:44:45 +00:00
u16 search_remaining = read_u16();
LibAudio: New error propagation API in Loader and Buffer Previously, a libc-like out-of-line error information was used in the loader and its plugins. Now, all functions that may fail to do their job return some sort of Result. The universally-used error type ist the new LoaderError, which can contain information about the general error category (such as file format, I/O, unimplemented features), an error description, and location information, such as file index or sample index. Additionally, the loader plugins try to do as little work as possible in their constructors. Right after being constructed, a user should call initialize() and check the errors returned from there. (This is done transparently by Loader itself.) If a constructor caused an error, the call to initialize should check and return it immediately. This opportunity was used to rework a lot of the internal error propagation in both loader classes, especially FlacLoader. Therefore, a couple of other refactorings may have sneaked in as well. The adoption of LibAudio users is minimal. Piano's adoption is not important, as the code will receive major refactoring in the near future anyways. SoundPlayer's adoption is also less important, as changes to refactor it are in the works as well. aplay's adoption is the best and may serve as an example for other users. It also includes new buffering behavior. Buffer also gets some attention, making it OOM-safe and thereby also propagating its errors to the user.
2021-11-27 16:00:19 +00:00
CHECK_OK(LoaderError::Category::IO, "Reading remaining bytes searching for data");
Everywhere: Make ByteBuffer::{create_*,copy}() OOM-safe
2021-09-05 22:59:52 +00:00
if (search_remaining != 0x6174) // TA
WavLoader: Search for DATA marker by reading single bytes Previously 4 bytes at once were read and compared to the string "DATA". This worked when the DATA marker was aligned on a 32-bit boundary relative to the start of the file. However, this is not guranteed to always be the case, and for some files the loader would just keep searching for the marker.
2020-06-18 18:00:32 +00:00
continue;
LibAudio: Allow loading sounds from memory The Loader and WavLoaderPlugin classes now have methods for loading from a ByteBuffer, in addition to streaming from disk.
2020-12-02 14:44:45 +00:00
data_sz = read_u32();
WavLoader: Search for DATA marker by reading single bytes Previously 4 bytes at once were read and compared to the string "DATA". This worked when the DATA marker was aligned on a 32-bit boundary relative to the start of the file. However, this is not guranteed to always be the case, and for some files the loader would just keep searching for the marker.
2020-06-18 18:00:32 +00:00
found_data = true;
break;
AudioServer: Assorted infrastructure work * Add a LibAudio, and move WAV file parsing there (via AWavFile and AWavLoader) * Add CLocalSocket, and CSocket::connect() variant for local address types. We make some small use of this in WindowServer (as that's where we modelled it from), but don't get too invasive as this PR is already quite large, and the WS I/O is a bit carefully done * Add an AClientConnection which will eventually be used to talk to AudioServer (and make use of it in Piano, though right now it really doesn't do anything except connect, using our new CLocalSocket...)
2019-07-13 17:42:03 +00:00
}
ok = ok && found_data;
LibAudio: New error propagation API in Loader and Buffer Previously, a libc-like out-of-line error information was used in the loader and its plugins. Now, all functions that may fail to do their job return some sort of Result. The universally-used error type ist the new LoaderError, which can contain information about the general error category (such as file format, I/O, unimplemented features), an error description, and location information, such as file index or sample index. Additionally, the loader plugins try to do as little work as possible in their constructors. Right after being constructed, a user should call initialize() and check the errors returned from there. (This is done transparently by Loader itself.) If a constructor caused an error, the call to initialize should check and return it immediately. This opportunity was used to rework a lot of the internal error propagation in both loader classes, especially FlacLoader. Therefore, a couple of other refactorings may have sneaked in as well. The adoption of LibAudio users is minimal. Piano's adoption is not important, as the code will receive major refactoring in the near future anyways. SoundPlayer's adoption is also less important, as changes to refactor it are in the works as well. aplay's adoption is the best and may serve as an example for other users. It also includes new buffering behavior. Buffer also gets some attention, making it OOM-safe and thereby also propagating its errors to the user.
2021-11-27 16:00:19 +00:00
CHECK_OK(LoaderError::Category::Format, "Found no data chunk");
AK/LibAudio: Add stream read operators to AK::BufferStream, and use it in AWavLoader At the same time, we allow chaining of streaming operators, and add a way to check for partial reads (also used in WAV parsing).
2019-07-13 22:28:30 +00:00
LibAudio: decrease WavLoader's size limit to a more reasonable size A 4 GiB wav (current size limit) is very unreasonable, and larger than oss-fuzz's 2.5 GiB per-process memory limit.
2021-03-16 17:05:59 +00:00
ok = ok && data_sz < maximum_wav_size;
LibAudio: New error propagation API in Loader and Buffer Previously, a libc-like out-of-line error information was used in the loader and its plugins. Now, all functions that may fail to do their job return some sort of Result. The universally-used error type ist the new LoaderError, which can contain information about the general error category (such as file format, I/O, unimplemented features), an error description, and location information, such as file index or sample index. Additionally, the loader plugins try to do as little work as possible in their constructors. Right after being constructed, a user should call initialize() and check the errors returned from there. (This is done transparently by Loader itself.) If a constructor caused an error, the call to initialize should check and return it immediately. This opportunity was used to rework a lot of the internal error propagation in both loader classes, especially FlacLoader. Therefore, a couple of other refactorings may have sneaked in as well. The adoption of LibAudio users is minimal. Piano's adoption is not important, as the code will receive major refactoring in the near future anyways. SoundPlayer's adoption is also less important, as changes to refactor it are in the works as well. aplay's adoption is the best and may serve as an example for other users. It also includes new buffering behavior. Buffer also gets some attention, making it OOM-safe and thereby also propagating its errors to the user.
2021-11-27 16:00:19 +00:00
CHECK_OK(LoaderError::Category::Format, "Data was too large");
AK/LibAudio: Add stream read operators to AK::BufferStream, and use it in AWavLoader At the same time, we allow chaining of streaming operators, and add a way to check for partial reads (also used in WAV parsing).
2019-07-13 22:28:30 +00:00
LibAudio: Avoid reading past the end of sample data Prior code in `WavLoader::get_more_samples()` would attempt to read the requested number of samples without actually checking whether that many samples were remaining in the stream. This was the cause of an audible pop at the end of a track, due to reading non-audio data that is sometimes at the end of a Wave file. Now we only attempt to read up to the end of sample data, but no further. Also, added comments to clarify the meaning of "sample", and how it should be independent of the number of channels.
2021-06-10 17:59:00 +00:00
m_total_samples = data_sz / block_size_bytes;
LibAudio+aplay: Make the aplay output look a little funner. Show some information about the file we're playing, and display how many samples we've played out of how many total. This might be a bit buggy as I haven't tested it with many different files, but it's a start. :^)
2019-07-28 19:52:30 +00:00
LibAudio: WavLoader: Avoid reading partial samples When samples are requested in `Audio::Loader::get_more_samples`, the request comes in as a max number of bytes to read. However, the requested number of bytes may not be an even multiple of the bytes per sample of the loaded file. If this is the case, and the bytes are read from the file/stream, then the last sample will be a partial/runt sample, which then offsets the remainder of the stream, causing white noise in playback. This bug was discovered when trying to play 24-bit Wave files, which happened to have a sample size that never aligned with the number of requested bytes. This commit fixes the bug by only reading a multiple of "bytes per sample" for the loaded file.
2021-06-05 17:14:03 +00:00
dbgln_if(AWAVLOADER_DEBUG, "WAV data size {}, bytes per sample {}, total samples {}",
data_sz,
LibAudio: Avoid reading past the end of sample data Prior code in `WavLoader::get_more_samples()` would attempt to read the requested number of samples without actually checking whether that many samples were remaining in the stream. This was the cause of an audible pop at the end of a track, due to reading non-audio data that is sometimes at the end of a Wave file. Now we only attempt to read up to the end of sample data, but no further. Also, added comments to clarify the meaning of "sample", and how it should be independent of the number of channels.
2021-06-10 17:59:00 +00:00
block_size_bytes,
LibAudio: WavLoader: Avoid reading partial samples When samples are requested in `Audio::Loader::get_more_samples`, the request comes in as a max number of bytes to read. However, the requested number of bytes may not be an even multiple of the bytes per sample of the loaded file. If this is the case, and the bytes are read from the file/stream, then the last sample will be a partial/runt sample, which then offsets the remainder of the stream, causing white noise in playback. This bug was discovered when trying to play 24-bit Wave files, which happened to have a sample size that never aligned with the number of requested bytes. This commit fixes the bug by only reading a multiple of "bytes per sample" for the loaded file.
2021-06-05 17:14:03 +00:00
m_total_samples);
LibAudio: Make Loader::seek() treat its input as a sample index This fixes a bug where if you try to play a Wave file a second time (or loop with `aplay -l`), the second time will be pure noise. The function `Audio::Loader::seek` is meant to seek to a specific audio sample, e.g. seek(0) should go to the first audio sample. However, WavLoader was interpreting seek(0) as the beginning of the file or stream, which contains non-audio header data. This fixes the bug by capturing the byte offset of the start of the audio data, and offseting the raw file/stream seek by that amount.
2021-06-06 00:14:55 +00:00
m_byte_offset_of_data_samples = bytes_read;
LibAudio: New error propagation API in Loader and Buffer Previously, a libc-like out-of-line error information was used in the loader and its plugins. Now, all functions that may fail to do their job return some sort of Result. The universally-used error type ist the new LoaderError, which can contain information about the general error category (such as file format, I/O, unimplemented features), an error description, and location information, such as file index or sample index. Additionally, the loader plugins try to do as little work as possible in their constructors. Right after being constructed, a user should call initialize() and check the errors returned from there. (This is done transparently by Loader itself.) If a constructor caused an error, the call to initialize should check and return it immediately. This opportunity was used to rework a lot of the internal error propagation in both loader classes, especially FlacLoader. Therefore, a couple of other refactorings may have sneaked in as well. The adoption of LibAudio users is minimal. Piano's adoption is not important, as the code will receive major refactoring in the near future anyways. SoundPlayer's adoption is also less important, as changes to refactor it are in the works as well. aplay's adoption is the best and may serve as an example for other users. It also includes new buffering behavior. Buffer also gets some attention, making it OOM-safe and thereby also propagating its errors to the user.
2021-11-27 16:00:19 +00:00
return {};
Work on AudioServer The center of this is now an ABuffer class in LibAudio. ABuffer contains ASample, which has two channels (left/right) in floating point for mixing purposes, in 44100hz. This means that the loaders (AWavLoader in this case) needs to do some manipulation to get things in the right format, but that we don't need to care after format loading is done. While we're at it, do some correctness fixes. PCM data is unsigned if it's 8 bit, but 16 bit is signed. And /dev/audio also wants signed 16 bit audio, so give it what it wants. On top of this, AudioServer now accepts requests to play a buffer. The IPC mechanism here is pretty much a 1:1 copy-paste from LibGUI/WindowServer. It can be generalized more in the future, but for now I want to get AudioServer working decently first :) Additionally, add a little "aplay" tool to load and play a WAV file. It will break with large WAVs (run out of memory, heh...) but it's a start. Future work needs to make AudioServer block buffer submission from clients until it has played the buffer they are requesting to play.
2019-07-15 10:54:52 +00:00
}
}
Reference in a new issue Copy permalink