| Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
The reduction in size from 0x38 to 0x34 caused the parameter to be misaligned. Skipping 1 word fixes this.
|
|
|
|
|
|
|
|
|
|
Converts services to have their own processes
|
|
|
|
This reverts commit 25fc5c0e1158cb8e81cbc769b24ad84032a1fbfd, reversing
changes made to af20e25081f97d55b451606c87922e2b49f0d363.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- This was arbitrarily added by me, and does not appear to be helpful.
|
|
|
|
|
|
These member functions don't modify any internal state.
|
|
|
|
|
|
This formats all copyright comments according to SPDX formatting guidelines.
Additionally, this resolves the remaining GPLv2 only licensed files by relicensing them to GPLv2.0-or-later.
|
|
|
|
|
|
|
|
The service context helps to manage all created events and allows us to close them upon destruction.
|
|
|
|
|
|
|
|
Currently, processing of audio samples is called from AudioRenderer's Update method, using a fixed 4 buffers to process the given samples. Games call Update at variable rates, depending on framerate and/or sample count, which causes inconsistency in audio processing. From what I've seen, 60 FPS games update every ~0.004s, but 30 FPS/160 sample games update somewhere between 0.02 and 0.04, 5-10x slower. Not enough samples get fed to the backend, leading to a lot of audio skipping.
This PR seeks to address this by de-coupling the audio consumption and the audio update. Update remains the same without calling for buffer queuing, and the consume now schedules itself to run based on the sample rate and count.
|
|
Transition to PascalCase for result names.
|
|
Now that we have most of core free of shadowing, we can enable the
warning as an error to catch anything that may be remaining and also
eliminate this class of logic bug entirely.
|
|
|
|
|
|
|
|
|
|
Now all that remains is for kernel code to be 'shadow-free' and then
-Wshadow can be turned into an error.
|
|
|
|
|
|
|
|
|
|
- This makes it such that we can safely access service members from CoreTiming thread.
|
|
Completely removes all usages of the global system instance within the
services code by passing in the using system instance to the services.
|
|
|
|
* audio_renderer: Preliminary BehaviorInfo
* clang format
* Fixed IsRevisionSupported
* fixed IsValidRevision
* Fixed logic error & spelling errors & crash
* Addressed issues
|
|
|
|
These aren't used, so they should be removed to reduce compilation
warnings.
|
|
Allows reporting more cases where logic errors may exist, such as
implicit fallthrough cases, etc.
We currently ignore unused parameters, since we currently have many
cases where this is intentional (virtual interfaces).
While we're at it, we can also tidy up any existing code that causes
warnings. This also uncovered a few bugs as well.
|
|
Amends a few interfaces to be able to handle the migration over to the
new Memory class by passing the class by reference as a function
parameter where necessary.
Notably, within the filesystem services, this eliminates two ReadBlock()
calls by using the helper functions of HLERequestContext to do that for
us.
|
|
- This does not actually seem to exist in the real kernel - games reset these automatically.
# Conflicts:
# src/core/hle/service/am/applets/applets.cpp
# src/core/hle/service/filesystem/fsp_srv.cpp
|
|
|
|
We can remove this since its already a f32 value
|
|
|
|
|
|
Volume is a f32 value. (SwIPC describes it as a u32, but it is actually f32 as corroborated by switchbrew docs and SetAudioDeviceOutputVolume)
```cpp
const f32 volume = rp.Pop<f32>();
```
|
|
|
|
Audio devices use the supplied revision information in order to
determine if USB audio output is able to be supported. In this case, we
can only really handle using this revision information in
ListAudioDeviceName(), where it checks if USB audio output is supported
before supplying it as a device name.
A few other scenarios exist where the revision info is checked, such as:
- Early exiting from SetAudioDeviceOutputVolume if USB audio is
attempted to be set when that device is unsupported.
- Early exiting and returning 0.0f in GetAudioDeviceOutputVolume when
USB output volume is queried and it's an unsupported device.
- Falling back to AHUB headphones in GetActiveAudioDeviceName when the
device type is USB output, but is unsupported based off the revision
info.
In order for these changes to also be implemented, a few other changes
to the interface need to be made.
Given we now properly handle everything about ListAudioDeviceName(), we
no longer need to describe it as a stubbed function.
|
|
The revision querying facilities are used by more than just audren. e.g.
audio devices can use this to test whether or not USB audio output is
supported.
This will be used within the following change.
|
|
Trims out the lingering reliance on global state out of the audio code.
|
|
This service function only ever returns a result and nothing more.
|
|
AudioDevice and AudioInterface aren't valid device names on the Switch.
We should also be returning consistent names in
GetActiveAudioDeviceName().
While we're at it, we can also handle proper name output in
ListAudioDeviceName, by returning all the available devices on the
Switch.
|
|
|
|
Creating multiple "AudioRenderer" threads cause the previous thread to be overwritten. The thread will name be renamed to AudioRenderer-InstanceX, where X is the current instance number.
|
|
The event should only be signaled when an output audio device gets changed. Example, Speaker to USB headset. We don't identify different devices internally yet so there's no need to signal the event yet.
|
|
Even though it has been proven that IAudioRenderer:SystemEvent is
actually an automatic event. The current implementation of such event is
all thought to be manual. Thus it's implementation needs to be corrected
when doing such change. As it is right now this PR introduced a series
of regressions on softlocks on multiple games. Therefore, this pr
reverts such change until a correct implementation is made.
|
|
This is actually an auto-reset event in the audio service itself, not a
manual one.
|
|
Renames the members to more accurately indicate what they signify.
"OneShot" and "Sticky" are kind of ambiguous identifiers for the reset
types, and can be kind of misleading. Automatic and Manual communicate
the kind of reset type in a clearer manner. Either the event is
automatically reset, or it isn't and must be manually cleared.
The "OneShot" and "Sticky" terminology is just a hold-over from Citra
where the kernel had a third type of event reset type known as "Pulse".
Given the Switch kernel only has two forms of event reset types, we
don't need to keep the old terminology around anymore.
|
|
Also introduced in REV5 was a variable-size audio command buffer. This
also affects how the size of the work buffer should be determined, so we
can add handling for this as well.
Thankfully, no other alterations were made to how the work buffer size
is calculated in 7.0.0-8.0.0. There were indeed changes made to to how
some of the actual audio commands are generated though (particularly in
REV7), however they don't apply here.
|
|
Introduced in REV5. This is trivial to add support for, now that
everything isn't a mess of random magic constant values.
All this is, is a change in data type sizes as far as this function
cares.
|
|
"Unmagics" quite a few magic constants within this code, making it much
easier to understand. Particularly given this factors out specific
sections into their own self-contained lambda functions.
|
|
In several places, we have request parsers where there's nothing to
really parse, simply because the HLE function in question operates on
buffers. In these cases we can just remove these instances altogether.
In the other cases, we can retrieve the relevant members from the parser
and at least log them out, giving them some use.
|
|
Places all error codes in an easily includable header.
This also corrects the unsupported error code (I accidentally used the
hex value when I meant to use the decimal one).
|
|
This currently has the same behavior as the regular
OpenAudioRenderer API function, so we can just move the code within
OpenAudioRenderer to an internal function that both service functions
call.
|
|
This service function appears to do nothing noteworthy on the switch.
All it does at the moment is either return an error code or abort the
system. Given we obviously don't want to kill the system, we just opt
for always returning the error code.
|
|
Provides names for previously unknown entries (aside from the two u8
that appear to be padding bytes, and a single word that also appears
to be reserved or padding).
This will be useful in subsequent changes when unstubbing behavior related
to the audio renderer services.
|
|
Gets rid of the largest set of mutable global state within the core.
This also paves a way for eliminating usages of GetInstance() on the
System class as a follow-up.
Note that no behavioral changes have been made, and this simply extracts
the functionality into a class. This also has the benefit of making
dependencies on the core timing functionality explicit within the
relevant interfaces.
|
|
Updates function tables based off information provided by SwitchBrew.
|
|
|
|
|
|
|
|
Based off RE, they both currently go through the same codepath with no
difference in behavior.
|
|
These appear to be a basic getter and setter pair, so these are fairly
trivial to implement and get out of the way.
|
|
Updated based off information provided by Switchbrew.
|
|
Gets rid of a few indirect inclusions.
|
|
Preserves the meaning/type-safetiness of the stream state instead of
making it an opaque u32. This makes it usable for other things outside
of the service HLE context.
|
|
|
|
Due to keeping the code style consistent in the yuzu codebase. `rb = rp.MakeBuilder(...)` was replaced with `rb{ctx, ...}`
|
|
A few headers were including other headers when a forward declaration
can be used instead, allowing the include to be moved to the cpp file.
|
|
When a destructor isn't defaulted into a cpp file, it can cause the use
of forward declarations to seemingly fail to compile for non-obvious
reasons. It also allows inlining of the construction/destruction logic
all over the place where a constructor or destructor is invoked, which
can lead to code bloat. This isn't so much a worry here, given the
services won't be created and destroyed frequently.
The cause of the above mentioned non-obvious errors can be demonstrated
as follows:
------- Demonstrative example, if you know how the described error happens, skip forwards -------
Assume we have the following in the header, which we'll call "thing.h":
\#include <memory>
// Forward declaration. For example purposes, assume the definition
// of Object is in some header named "object.h"
class Object;
class Thing {
public:
// assume no constructors or destructors are specified here,
// or the constructors/destructors are defined as:
//
// Thing() = default;
// ~Thing() = default;
//
// ... Some interface member functions would be defined here
private:
std::shared_ptr<Object> obj;
};
If this header is included in a cpp file, (which we'll call "main.cpp"),
this will result in a compilation error, because even though no
destructor is specified, the destructor will still need to be generated by
the compiler because std::shared_ptr's destructor is *not* trivial (in
other words, it does something other than nothing), as std::shared_ptr's
destructor needs to do two things:
1. Decrement the shared reference count of the object being pointed to,
and if the reference count decrements to zero,
2. Free the Object instance's memory (aka deallocate the memory it's
pointing to).
And so the compiler generates the code for the destructor doing this inside main.cpp.
Now, keep in mind, the Object forward declaration is not a complete type. All it
does is tell the compiler "a type named Object exists" and allows us to
use the name in certain situations to avoid a header dependency. So the
compiler needs to generate destruction code for Object, but the compiler
doesn't know *how* to destruct it. A forward declaration doesn't tell
the compiler anything about Object's constructor or destructor. So, the
compiler will issue an error in this case because it's undefined
behavior to try and deallocate (or construct) an incomplete type and
std::shared_ptr and std::unique_ptr make sure this isn't the case
internally.
Now, if we had defaulted the destructor in "thing.cpp", where we also
include "object.h", this would never be an issue, as the destructor
would only have its code generated in one place, and it would be in a
place where the full class definition of Object would be visible to the
compiler.
---------------------- End example ----------------------------
Given these service classes are more than certainly going to change in
the future, this defaults the constructors and destructors into the
relevant cpp files to make the construction and destruction of all of
the services consistent and unlikely to run into cases where forward
declarations are indirectly causing compilation errors. It also has the
plus of avoiding the need to rebuild several services if destruction
logic changes, since it would only be necessary to recompile the single
cpp file.
|
|
As means to pave the way for getting rid of global state within core,
This eliminates kernel global state by removing all globals. Instead
this introduces a KernelCore class which acts as a kernel instance. This
instance lives in the System class, which keeps its lifetime contained
to the lifetime of the System class.
This also forces the kernel types to actually interact with the main
kernel instance itself instead of having transient kernel state placed
all over several translation units, keeping everything together. It also
has a nice consequence of making dependencies much more explicit.
This also makes our initialization a tad bit more correct. Previously we
were creating a kernel process before the actual kernel was initialized,
which doesn't really make much sense.
The KernelCore class itself follows the PImpl idiom, which allows
keeping all the implementation details sealed away from everything else,
which forces the use of the exposed API and allows us to avoid any
unnecessary inclusions within the main kernel header.
|
|
As we're not handling any anything about the revision data for GetAudioDeviceServiceWithRevisionInfo, it's currently marked as stubbed. However for games this shouldn't affect the result. Proper revision info would be more for homebrew.
|
|
|
|
GetAudioRendererSampleRate is set as a "STUB" as a game could check if the sample rate it sent and the sample rate it wants don't match. Just a thought of something which could happen so keeping it as stub for the mean time
|
|
|
|
|
|
std::string doesn't include the null-terminator in its data() + size()
range. This ensures that the null-terminator will also be written to the buffer
|
|
This introduces a slightly more generic variant of WriteBuffer().
Notably, this variant doesn't constrain the arguments to only accepting
std::vector instances. It accepts whatever adheres to the
ContiguousContainer concept in the C++ standard library.
This essentially means, std::array, std::string, and std::vector can be
used directly with this interface. The interface no longer forces you to
solely use containers that dynamically allocate.
To ensure our overloads play nice with one another, we only enable the
container-based WriteBuffer if the argument is not a pointer, otherwise
we fall back to the pointer-based one.
|
|
Prevents implicit construction and makes these lingering non-explicit
constructors consistent with the rest of the other classes in services.
|
|
|
|
|
|
* voice section updating
* fixed slight offset miscalculation
* fixed overflow
|
|
|
|
* We should be returning our revision instead of what is requested.
Hardware test on a 5.1.0 console
* Added sysversion comment
|
|
* Removed duplicate structs, changed AudioRendererResponse -> UpdateDataHeader
According to game symbols(SMO), there's references to UpdateDataHeader which seems to be what AudioRendererResponse actually is
* oops
* AudioRendererParameters should be AudioRendererParameter according to SMO
|
|
* Fixed RequestUpdateAudioRenderer deadlocks and calculated section sizes properly
This fixes RequestUpdateAudioRenderer deadlocks in games like Puyo Puyo Tetris and games which require a proper section size in games such as Retro City Rampage. This fixes causes various games to start rendering or trying to render
|
|
|
|
|
|
* GetAudioRendererWorkBufferSize impl
Impl of GetAudioRendererWorkBufferSize based on RE, if this can be cleaned up, please contribute!
* Naming conventions
* Removed unneeded placeholder
* lioncache changes
* fixed const
* switched to Common::AlignUp
|
|
* Add unknown function at the number command 2
* correct audout:u commands numbers
* correct audrec:u cmd number & add Unknown function
* correct IAudioDevice command numbers
* correct codecctl cmd numbers & rename the 8 function
* correct place of unknown function & fix clang-format
|
|
All of these variables and functions are related to timings and should be within the namespace.
|
|
|
|
|
|
|
|
Tidies up namespace declarations
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* audren_u: Schedule reoccuring event.
* audren_u: Stub GetAudioRenderersProcessMasterVolume, and misc. changes.
|
|
|
|
|
|
* stubs for audout:u, audin:u, audrec:u, audren:u, codecctl and decoding tables with nullptr for future implementations
* fixing the changes requested (remove private, explicit)
|
