What about DSP HLE?
We can use LLE to figure out missing protocol in HLE (pipe3, aac decoding etc.) and stub/fix/implement them.
@B3n30 has been making great progress on this.
Well if the extra sounds was already in WriteProcessPipe and implementing Binary linked to PipeWrite
in hle.cpp , Then the Music must be working off LoadComponent are other's hes using within his LLE on Binary are Buffer maybe..
Edit Are without this ^ , Can just put a LOG_WARNING on ReadPipeIfPossible and see what it Reads on Log are CMD on his branch while the music part.
----------
WriteProcessPipe:102: channel=2, size=0x4, buffer_size=4
EDIT:
HLE
ReadPipeIfPossible:163: channel=3, peer=0, size=0x0020, pipe_readable_size=0x0000
LLE
ReadPipeIfPossible:163: channel=3, peer=0, size=0x0020, pipe_readable_size=0x0020
HLE:
No Warnings
LLE:
WriteProcessPipe:102: channel=3, size=0x20, buffer_size=20
Making one
Code:
// This behaviour was confirmed by RE.
// The likely reason for this is that games tend to pass in garbage at these bytes
// because they read random bytes off the stack.
switch (pipe) {
case DspPipe::Audio:
ASSERT(buffer.size() >= 4);
buffer[4] = 1;
break;
case DspPipe::Binary:
ASSERT(buffer.size() >= 8);
buffer[4] = 1;
buffer[20] = 1;
break;
}
But ReadPipeIfPossible ?
This is braking it are else it dose not appear in LLE
Code:
[ 30.035654] Service.DSP <Info> core\hle\service\dsp\dsp_dsp.cpp:Service::DSP::DSP_DSP::RegisterInterruptEvents:251: Unregistered interrupt=2, channel=3
[ 30.043343] HW.Memory <Error> core\memory.cpp:Memory::MemorySystem::Read:140: unmapped Read8 @ 0x00000050;
Are Maybe LLE: LoadComponent:180: called size=0x35378, prog_mask=0x000300FF, data_mask=0x003500FF