| Age | Commit message (Collapse) | Author |
|---|
|
This change unfortunately cannot be atomically made without a single
commit changing everything.
Most of the important changes are in LibIPC/Connection.cpp,
LibIPC/ServerConnection.cpp and LibCore/LocalServer.cpp.
The notable changes are:
- IPCCompiler now generates the decode and decode_message functions such
that they take a Core::Stream::LocalSocket instead of the socket fd.
- IPC::Decoder now uses the receive_fd method of LocalSocket instead of
doing system calls directly on the fd.
- IPC::ConnectionBase and related classes now use the Stream API
functions.
- IPC::ServerConnection no longer constructs the socket itself; instead,
a convenience macro, IPC_CLIENT_CONNECTION, is used in place of
C_OBJECT and will generate a static try_create factory function for
the ServerConnection subclass. The subclass is now responsible for
passing the socket constructed in this function to its
ServerConnection base; the socket is passed as the first argument to
the constructor (as a NonnullOwnPtr<Core::Stream::LocalServer>) before
any other arguments.
- The functionality regarding taking over sockets from SystemServer has
been moved to LibIPC/SystemServerTakeover.cpp. The Core::LocalSocket
implementation of this functionality hasn't been deleted due to my
intention of removing this class in the near future and to reduce
noise on this (already quite noisy) PR.
|
|
The format of these names is "Full Abbreviation (.fileformat)". For
example: "FLAC (.flac)", "RIFF WAVE (.wav)", "MPEG Layer III (.mp3)",
"Vorbis (.ogg)" The reasoning is that the container and therefore the
file ending may differ significantly from the actual format, and the
format should be given as unambiguously as possible and necessary.
|
|
|
|
FixedArray now doesn't expose any infallible constructors anymore.
Rather, it exposes fallible methods. Therefore, it can be used for
OOM-safe code.
This commit also converts the rest of the system to use the new API.
However, as an example, VMObject can't take advantage of this yet,
as we would have to endow VMObject with a fallible static
construction method, which would require a very fundamental change
to VMObject's whole inheritance hierarchy.
|
|
|
|
Previously, FlacLoader would read the data for each frame into a
separate vector, which are then combined via extend() in the end. This
incurs an avoidable copy per frame. By having the next_frame() function
write into a given Span, there's only one vector allocated per call to
get_more_samples().
This increases performance by at least 100% realtime, as measured by
abench, from about 1200%-1300% to (usually) 1400% on complex test files.
|
|
A FixedArray, due to its non-allocation guarantee, is great for audio
programming, so it's natural to have it interface with Buffer.
|
|
The 'muted' methods referred to the 'main mix muted' but it wasn't
really clear from the name. This change will be useful because in the
next commit, a 'self muted' state will be added to each audio client
connection.
|
|
|
|
Thanks @alimpfard for pointing that out :^)
|
|
This makes it easier to fine-tune the optimal input buffer size.
|
|
As long as possible, entire decoded frame sample vectors are moved into
the output vector, leading to up to 20% speedups by avoiding memmoves on
take_first.
|
|
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.
|
|
This consists of two changes: First, a utility function create_empty
allows the user to quickly create an empty buffer. Second, most creation
functions now return a NonnullRefPtr, as their failure causes a VERIFY
crash anyways.
|
|
Decoding the residual in FLAC subframes is by far the most I/O-heavy
operation in FLAC decoding, as the residual data makes up the majority
of subframe data in LPC subframes. As the residual consists of many
Rice-encoded numbers with different bit sizes for differently large
numbers, the residual decoder frequently reads only one or two bytes at
a time. As we use a normal FileInputStream, that directly translates to
many calls to the read() syscall. We can see that the I/O overhead while
FLAC decoding is quite large, and much time is spent in the read()
syscall's kernel code.
This is optimized by using a Buffered<FileInputStream> instead, leading
to 4K blocks being read at once and a large reduction in I/O overhead.
Benchmarking with the new abench utility gives a 15-20% speedup on
identical files, usually pushing FLAC decoding to 10-15x realtime speed
on common sample rates.
|
|
|
|
Some nuances in the FLAC loading code can do well with an explanation,
as these non-obvious insights are often the result of long and painful
debugging and nobody should touch the affected code without careful
deliberation.
(Of course, secretly I just want people to maintain my loader code.)
:^)
|
|
This fixes all current code smells, bugs and issues reported by
SonarCloud static analysis. Other issues are almost exclusively false
positives. This makes much code clearer, and some minor benefits in
performance or bug evasion may be gained.
|
|
|
|
This little functional change uses the most common algorithm for panning
audio, known as constant power panning. It makes it so that the total
output power (not directly the sample value, i.e. the peak) stays the
same no matter how the audio is panned.
|
|
This makes the code easier to read.
|
|
"Frame" is an MPEG term, which is not only unintuitive but also
overloaded with different meaning by other codecs (e.g. FLAC).
Therefore, use the standard term Sample for the central audio structure.
The class is also extracted to its own file, because it's becoming quite
large. Bundling these two changes means not distributing similar
modifications (changing names and paths) across commits.
Co-authored-by: kleines Filmröllchen <malu.bertsch@gmail.com>
|
|
The conversion from a linear scale (how we think about audio) to a
logarithmic scale (how audio actually works) will be useful for other
operations, so let's extract it to its own utility function. Its inverse
will also allow reversible operations to be written more easily.
|
|
|
|
Derivatives of Core::Object should be constructed through
ClassName::construct(), to avoid handling ref-counted objects with
refcount zero. Fixing the visibility means that misuses like this are
more difficult.
|
|
Note: While ClientAudioStream has had a volume property, it is only now
used in the mixer.
|
|
With logarithmic volume scaling, the delay effect can sound more
natural.
|
|
Across the entire audio system, audio now works in 0-1 terms instead of
0-100 as before. Therefore, volume is now a double instead of an int.
The master volume of the AudioServer changes smoothly through a
FadingProperty, preventing clicks. Finally, volume computations are done
with logarithmic scaling, which is more natural for the human ear.
Note that this could be 4-5 different commits, but as they change each
other's code all the time, it makes no sense to split them up.
|
|
|
|
They're mostly used in literal random data, so it isn't like
there is a high demand for it, but it's cool to have more complete
implementation anyway. :^)
|
|
LibDSP is a library for digital signal processing, and is primarily
intended to support the future DAW version of Piano.
|
|
All audio applications (aplay, Piano, Sound Player) respect the ability
of the system to have theoretically any sample rate. Therefore, they
resample their own audio into the system sample rate.
LibAudio previously had its loaders resample their own audio, even
though they expose their sample rate. This is now changed. The loaders
output audio data in their file's sample rate, which the user has to
query and resample appropriately. Resampling code from Buffer, WavLoader
and FlacLoader is removed.
Note that these applications only check the sample rate at startup,
which is reasonable (the user has to restart applications when changing
the sample rate). Fully dynamic adaptation could both lead to errors and
will require another IPC interface. This seems to be enough for now.
|
|
FlacLoader initialized, but never used its resampler; this is now fixed
and all subframes are resampled before decorrelation occurs. FLAC files
with non-44100-Hz sample rates now play properly.
|
|
Floating-point ratios are inherently imprecise, and can lead to
unpredictable or nondeterministic behavior when resampling and expecting
a certain number of resulting samples. Therefore, the resampler now uses
integer ratios, with almost identical but fully predictable behavior.
This also introduces the reset() function that the FLAC loader will use
in the future.
|
|
When computing sample values from a linear predictor, the repeated
multiplication and addition can lead to very large values that may
overflow a 32-bit integer. This was never discovered with 16-bit FLAC
test files used to create and validate the first version of the FLAC
loader. However, 24-bit audio, especially with large LPC shifts, will
regularly exceed and overflow i32. Therefore, we now use 64 bits
temporarily. If the resulting value is too large for 32 bits, something
else has gone wrong :^)
This fixes playback noise on 24-bit FLACs.
|
|
The FLAC samples are signed, so we need to rescale them not by their bit
depth, but by half of the bit depth. For example, a 24-bit sample
extends from -2^23 to 2^23-1, and therefore needs to be rescaled by 2^23
to conform to the [-1, 1] double sample range.
|
|
This is more idiomatic :^)
|
|
Playing a lossy flac file resulted in hearing something
you'd not like to play. Instead of your lovely bass, you had sounds
as if you put a CD-ROM disc to a CD player.
It turned out that the size for making signed values was too big,
making all the values unsigned.
I've used lossyWav[1] (the posix port[2] to be exact)
to generate such files.
[1]: https://wiki.hydrogenaud.io/index.php?title=LossyWAV
[2]: https://github.com/MoSal/lossywav-for-posix
|
|
The value was always zero.
|
|
Prior this change, decoding fixed subframes produced "unpleasant
crackling noices".
While the type doesn't appear so often when using the default settings,
encoding files in flac(1) with --fast option uses fixed subframes
almost every time.
This also applies the logic to the constant subframes,
which isn't so important, as the type is generally for the silence,
but let's use it as well to avoid inconsistency.
|
|
Before this change the file stream was generated two times:
one time in the parse_header(), and another time for the whole class
in the constructor.
The previous commit moved the m_stream initialization before
executing the parse_header function, so we can now reuse that here.
|
|
Before this change opening the file in the system resulted in crash
caused by assertion saying:
SoundPlayer(32:32): ASSERTION FAILED: m_ptr
../.././AK/OwnPtr.h:139
[#0 SoundPlayer(32:32)]: Terminating SoundPlayer(32) due to signal 6
[#0 FinalizerTask(4:4)]: 0xdeadc0de
The issue was that 845d403b8c175ff99793239404ca8657d95da104 started
using m_stream in the parse_header() function, but that variable wasn't
initialized if the Loader plugin was created using a file path
(which is used everywhere except for the fuzz testing),
resulting in a crash mentioned above.
|
|
The FlacLoader already has numerous checks for invalid data reads and
for invalid stream states, but it never actually handles the stream
errors on the stream object. By handling them properly we can actually
run FuzzFlacLoader for longer than a few seconds before it hits the
first assertion :^).
|
|
This makes aplay show current playback position.
|
|
This fixes stucking in a loop at the end of the file, as
(a) custom block sizes are usually placed there, as the remaining
size might not be simply calculated as a power of two, and
(b) the number of bytes to read was incorrect (the program said
the block size was 32525, where flac -a said it's actually 3200).
Unfortunately, I couldn't trigger the bug for the sample rates,
so it may be not true, but I'd doubt it, giving the fact that flac
almost everywhere uses big endian numbers.
|
|
This fixes crash when reading the end of the file.
The logic is mostly borrowed from WavLoader.
|
|
The problem here was that the multi-byte UTF-8 encoded characters
were taking one byte too much, misaligning the data completely
and eventually crashing the program on the 128th frame.
This change reduces the for loop by one, as it has been already
calculated from the start_byte variable.
|
|
This might allow the program to return an error a bit quicker.
|
|
AK's version should see better inlining behaviors, than the LibM one.
We avoid mixed usage for now though.
Also clean up some stale math includes and improper floatingpoint usage.
|
|
|
