* HLE Audio: Increase frame position by input buffer sample rate
Currently the frame position moves ahead by the number of samples
output, but thats a fixed number based on the 3ds native sample rate.
Instead, based on a homebrew by cyuubi and looking at the lle audio,
this sample position should be moved forward by the number of samples
from the input buffer that was read, based on the buffer's sample rate.
* audio_core: dsp_hle: implements fdk_aac decoder
* audio_core: dsp_hle: clean up and add comments
* audio_core: dsp_hle: move fdk include to cpp file
* audio_core: dsp_hle: detects broken fdk_aac...
... and refuses to initialize if that's the case
* audio_core: dsp_hle: fdk_aac: address comments...
... and rebase commits
* fdk_decoder: move fdk header to cpp file
Simple cut/paste issue where initialized is only set to true when the
emulation attempts to init the Binary Pipe, but we used it to test if
the FFMPEG decoder was valid and disabled it if it wasn't. Just return
the value of have_ffmpeg_dl instead so when dynamic loading is added
it'll still work.
HACK
In Luigi's Mansion Dark Moon in HLE audio, the game mysteriously passes
in an extremely large value for length, which without any checks, causes
HLE audio to allocate an extremely large buffer.
This value seemingly is caused by some other HLE audio feature is missing,
and Luigi's Mansion subtracts two values to get a length, without
checking for overflow first. This appears to be caused by an incorrect
HLE audio emulation, as its fixed entirely by only changing to LLE. As
such, further investigation is required, but in the meantime, completely
eating up our users RAM is unacceptable.
This commit it automatically generated by command in zsh:
sed -i -- 's/BitField<\(.*\)_le>/BitField<\1>/g' **/*(D.)
BitField is now aware to endianness and default to little endian. It expects a value representation type without storage specification for its template parameter.
