| Age | Commit message (Collapse) | Author |
|---|
|
Fix Frame Advance and FifoPlayer pause/unpause/stop.
CPU::EnableStepping is not atomic but is called from multiple threads
which races and leaves the system in a random state; also instruction
stepping was unstable, m_StepEvent had an almost random value because
of the dual purpose it served which could cause races where CPU::Run
would SingleStep when it was supposed to be sleeping.
FifoPlayer never FinishStateMove()d which was causing it to deadlock.
Rather than partially reimplementing CPU::Run, just use CPUCoreBase
and then call CPU::Run(). More DRY and less likely to have weird bugs
specific to the player (i.e the previous freezing on pause/stop).
Refactor PowerPC::state into CPU since it manages the state of the
CPU Thread which is controlled by CPU, not PowerPC. This simplifies
the architecture somewhat and eliminates races that can be caused by
calling PowerPC state functions directly instead of using CPU's
(because they bypassed the EnableStepping lock).
|
|
CoreAudioSound: Minor clean up
|
|
The kAudioUnitParameterFlag_* parameters don't exist on iOS.
|
|
|
|
|
|
Gets defines out of global scope.
|
|
|
|
Nothing in the codebase inherits from this class
|
|
We don't throttle by frames, we throttle by coretiming speed.
So looking up VI for calculating the speed was just very wrong.
The new ini option is a float, 1.0f for fullspeed.
In the GUI, percentual values are used.
|
|
A failure on my part. I was updating the two buffers in the wrong order, so we were always a buffer behind in sending audio out to OpenSLES.
|
|
|
|
NullSound: Minor changes
|
|
Throttler + Mixer: Configureable variance
|
|
|
|
|
|
|
|
|
|
ALSA: Don't block on Clear() call.
|
|
Fix building with PCH disabled.
|
|
snd_pcm_writei() is meant to block block until all samples are written,
but apparently in some situations it can block for much longer, prehaps
even a infinite time, in the case of virtual machine FifoCI runs in.
Because it grabed a mutex before blocking, it could also block the
Clear() call for an infinite length of time, blocking dolphin's emu
thread.
snd_pcm_writei() also takes 10-15 seconds if you run dolphin under GDB
and can randomly take 5 or so seconds during normal usage.
By moving all the pause code to the ALSA thread, Clear() no-longer
blocks and everyone keeps their sanity.
|
|
|
|
|
|
|
|
|
|
|
|
MathUtil: Make Clamp and IsPow2 constexpr functions.
|
|
|
|
Fixed braces, first try fixing mac compilation and removed useless NULL
comparison.
|
|
|
|
Fix some small stuff found with Valgrind
|
|
Minor spelling corrections
|
|
|
|
When the emulation is paused and the ALSA backend is used, make the audio
thread wait on a condition variable instead of busy-waiting. This commit
fixes bug #7729
Since the ALSA API is not thread-safe, calls to snd_pcm_drop() and snd_pcm_prepare()
in AlsaSound::Clear() are protected by the same mutex as the condition variable in AlsaSound::SoundLoop()
to make sure that we do not call these functions while a call to
snd_pcm_writei() is ongoing.
|
|
This fixes a race condition:
Before this commit, there was a race condition when starting a game:
Core::EmuThread(), after having started (but not necessarily completed)
the initialization of the audio thread, calls Core::SetState() which calls
CCPU::EnableStepping(), which in turns calls AudioCommon::ClearAudioBuffer().
This means that SoundStream::Clear() can be called before
AlsaSound::AlsaInit() has completed.
|
|
AudioCommon: Log to AUDIO, not DSPHLE
|
|
If the selected audio backend fails to Start() (which could happen for
example if there is no audio device), we currently still use the backend
anyway. This can lead to crashes on some platforms (such as Windows) and
is outright wrong anyway.
This commit fallbacks to the Null audio backend if the selected backend
couldn't be started.
This fixes bug #6001
|
|
|
|
This code is not related to DSPHLE.
|
|
|
|
|
|
OpenALStream: Fix sample conversion.
|
|
Looks like it wasn't symmetric anymore.
|
|
|
|
Their functionality is already complete in the base class; there's no need to allow overriding.
|
|
|
|
It means less work for the translators... But I'm not too sure
about this, because most of these have already been translated.
|
|
We had to lock audiocommon with the old asynchron HLE audio emulation,
now our Mixer is just a plain FIFO which may underrun.
Of course, this will stutter, but underruning the audio backend is likely worse.
|
|
|
|
|
|
|
