If the seek table was incomplete, without any seek points available
before the target point, `SeekTable::seek_point_before()` would instead
return the first seek point after the target. Check whether the seek
point is before the target before returning it.
We downsample multi-channel files into stereo for now, which at least
makes the other channels listenable. The new multi-channel downmix
helper is intended to be used for other formats with the same or similar
channel arrangement, such as QOA.
Especially FLAC had an issue here before, but the loader infrastructure
itself wouldn't handle end of stream properly if the "available samples"
information didn't match up.
It's no longer needed now that this code uses ErrorOr instead of Result.
Ran:
rg -lw LOADER_TRY Userland/Libraries/LibAudio \
| xargs sed -i '' 's/LOADER_TRY/TRY/g'
...and then manually fixed up Userland/Libraries/LibAudio/LoaderError.h
to not redefine TRY but instead remove the now-unused LOADER_TRY,
and ran clang-format.
For very large seekpoint indices, the casts necessary for the "simple"
subtraction comparison will yield wrong and overflowing results.
Therefore, we perform the seekpoint comparison manually instead.
This specialized UTF-8 decoder is more powerful than a normal UTF-8
decoder anyways, but it couldn't account for the never spec-compliant
0xff start byte. This commit makes that byte behave as expected if
taking UTF-8 to its extreme, even if it is a little silly and likely not
relevant for real applications.
The bit magic for two's complement sign extension was only sign
extending to 32-bit signed. This issue was exposed by the last commit,
where now we actually use the 64-bit return value.
Since we can have up to 32 bits of input data, multiplications may need
up to 63 bits. This was accounted for in some places, but by far not in
all, and oss-fuzz found multiple integer overflows. We now use i64 in
all of the decoding, since we need to rescale samples to float later on
anyways. If a final sample value ends up out of range (and the range can
be a maximum of 32 bits), we may get samples past 1, but that then is a
non-compliant input file, and using over-range samples (and most likely
clipping audio) is considerably less weird than overflowing and
glitching audio.
The fuzzer found one heap buffer overflow here due to confusion between
u32* and u8* (the given size is for bytes, but we used it for 32-bit
elements, quadrupling it), and it looks like there's an opportunity for
several more. This commit modernizes the picture loader by using
String's built-in stream loader, and also adds several spec-compliance
checks: The MIME type must be ASCII in a specific range, and the picture
description must be UTF-8.
An LPC predictor (fixed or not) contains as many warm-up samples as its
order. Therefore, the corresponding subframe must have at least this
many samples.
This turns this fuzzer-found crash into a handleable format error.
There are at most 576 granule samples/frequency lines, but the side data
can specify that the big_values granule type take up to 1024 samples.
The spec says in 2.4.3.4.6 that we should always stop reading Huffman
data once we have 576 samples, so that is what this change does. I also
add some useful spec comments while I'm here.
This change was a long time in the making ever since we obtained sample
rate awareness in the system. Now, each client has its own sample rate,
accessible via new IPC APIs, and the device sample rate is only
accessible via the management interface. AudioServer takes care of
resampling client streams into the device sample rate. Therefore, the
main improvement introduced with this commit is full responsiveness to
sample rate changes; all open audio programs will continue to play at
correct speed with the audio resampled to the new device rate.
The immediate benefits are manifold:
- Gets rid of the legacy hardware sample rate IPC message in the
non-managing client
- Removes duplicate resampling and sample index rescaling code
everywhere
- Avoids potential sample index scaling bugs in SoundPlayer (which have
happened many times before) and fixes a sample index scaling bug in
aplay
- Removes several FIXMEs
- Reduces amount of sample copying in all applications (especially
Piano, where this is critical), improving performance
- Reduces number of resampling users, making future API changes (which
will need to happen for correct resampling to be implemented) easier
I also threw in a simple race condition fix for Piano's audio player
loop.
This removes a lot of duplicated stream creation code from the plugins,
and also simplifies the way that the appropriate plugin is found. This
mirrors the ImageDecoderPlugin design and necessitates new sniffing
methods on the loaders.
This is a sensible separation of concerns that mirrors the WindowServer
IPC split. On the one hand, there is the "normal" audio interface, used
for clients that play audio, which is the primary service of
AudioServer. On the other hand, there is the management interface,
which, like the WindowManager endpoint, provides higher-level control
over clients and the server itself.
The reasoning for this split are manifold, as mentioned we are mirroring
the WindowServer split. Another indication to the sensibility of the
split is that no single audio client used the APIs of both interfaces.
Also, useless audio queues are no longer created for managing clients
(since those don't even exist, just like there's no window backing
bitmap for window managing clients), eliminating any bugs that may occur
there as they have in the past.
Implementation-wise, we just move all the APIs and implementations from
the old AudioServer into the AudioManagerServer (and respective clients,
of course). There is one point of duplication, namely the hardware
sample rate. This will be fixed in combination with per-client sample
rate, eliminating client-side resampling and the related update bugs.
For now, we keep one legacy API to simplify the transition.
The new AudioManagerServer also gains a hardware sample rate change
callback to have exact symmetry on the main server parameters (getter,
setter, and callback).
WavWriter needs a TON of modernization work, but for now this commit
just tackles two FIXMEs by converting samples correctly into all
supported integer PCM formats. The supported formats are only signed
16-bit and unsigned 8-bit for now, but can be expanded later. At least
we don't produce horrible speaker-destroying noise when writing any
other format.
With this, the WAV loader is a completely modern LibAudio loader:
- Own type header for RIFF data structures
- custom stream read functions for the types
- Final removal of legacy I/O error checking
- clearer error messages
- clean handling of header chunks
The latter will allow proper handling of other chunks (before "data") in
the future, such as metadata :^)
That's what this class really is; in fact that's what the first line of
the comment says it is.
This commit does not rename the main files, since those will contain
other time-related classes in a little bit.
`WavWriter` can be constructed without a file, which should probably be
made impossible at some point. For now, let's not crash `Piano` when you
close the application.
This was used in exactly one place, to avoid sending multiple
CustomEvents to the enqueuer thread in Audio::ConnectionToServer.
Instead of this, we now just send a CustomEvent and wake the enqueuer
thread. If it wakes up and has multiple CustomEvents, they get delivered
and ignored in no time anyway. Since they only get ignored if there's
no work to be done, this seems harmless.
This is a special case of the sample count field in the header which we
treated as a format error before. Now we just take care to check stream
EOF before reading chunks.
This makes the final FLAC spec test pass, making us one of the most
compliant loaders! :^)
We report a rounded up PCM sample format to the outside, but use the
exact bit depth as specified in header and frames.
This makes the three FLAC spec tests with a a bit depth of 20 pass.
"Improve" is an understatement, since this commit makes all FLAC files
seek without errors, mostly with high accuracy, and partially even fast:
- A new generic seek table type is introduced, which keeps an
always-sorted list of seek points, which allows it to use binary
search and fast insertion.
- Automatic seek points are inserted according to two heuristics
(distance between seek points and minimum seek precision), which not
only builds a seek table for already-played sections of the file, but
improves seek precision even for files with an existing seek table.
- Manual seeking by skipping frames works properly now and is still used
as a last resort.
This container has several design goals:
- Represent all common and relevant metadata fields of audio files in a
unified way.
- Allow perfect recreation of any metadata format from the in-memory
structure. This requires that we allow non-detected fields to reside
in an "untyped" miscellaneous collection.
Like with pictures, plugins are free to store their metadata into the
m_metadata field whenever they read it. It is recommended that this
happens on loader creation; however failing to read metadata should not
cause an error in the plugin.
Similar to POSIX read, the basic read and write functions of AK::Stream
do not have a lower limit of how much data they read or write (apart
from "none at all").
Rename the functions to "read some [data]" and "write some [data]" (with
"data" being omitted, since everything here is reading and writing data)
to make them sufficiently distinct from the functions that ensure to
use the entire buffer (which should be the go-to function for most
usages).
No functional changes, just a lot of new FIXMEs.
Before, some loader plugins implemented their own buffering (FLAC&MP3),
some didn't require any (WAV), and some didn't buffer at all (QOA). This
meant that in practice, while you could load arbitrary amounts of
samples from some loader plugins, you couldn't do that with some others.
Also, it was ill-defined how many samples you would actually get back
from a get_more_samples call.
This commit fixes that by introducing a layer of abstraction between the
loader and its plugins (because that's the whole point of having the
extra class!). The plugins now only implement a load_chunks() function,
which is much simpler to implement and allows plugins to play fast and
loose with what they actually return. Basically, they can return many
chunks of samples, where one chunk is simply a convenient block of
samples to load. In fact, some loaders such as FLAC and QOA have
separate internal functions for loading exactly one chunk. The loaders
*should* load as many chunks as necessary for the sample count to be
reached or surpassed (the latter simplifies loading loops in the
implementations, since you don't need to know how large your next chunk
is going to be; a problem for e.g. FLAC). If a plugin has no problems
returning data of arbitrary size (currently WAV), it can return a single
chunk that exactly (or roughly) matches the requested sample count. If a
plugin is at the stream end, it can also return less samples than was
requested! The loader can handle all of these cases and may call into
load_chunk multiple times. If the plugin returns an empty chunk list (or
only empty chunks; again, they can play fast and loose), the loader
takes that as a stream end signal. Otherwise, the loader will always
return exactly as many samples as the user requested. Buffering is
handled by the loader, allowing any underlying plugin to deal with any
weird sample count requirement the user throws at it (looking at you,
SoundPlayer!).
This (not accidentally!) makes QOA work in SoundPlayer.
