rpglord Wrote:That functionality is already implemented in dolphin ! Its called enabling vbeam and disabling idle skipping
Not exactly, but the effect is close enough for what most of want (stutterless LLE audio :3) The CPU and DSP still need to run in sync, but those options seem to affect DMA timings (e.g. how the CPU sends audio data to ARAM, which the DSP reads) to be more accurate. If the emulated CPU is still too slow, the sound stutters and "pops" even with the VBeam trick. I guess the VBeam trick makes syncing with the CPU much easier for lower-end hardware, but the GPU probably doesn't need to run quite in sync with the CPU. That's why you can still have low FPS (e.g. 45) but still get perfect audio.
Of course, now I'm talking about things I don't really know (hence it's pretty much a guess), so I'd appreciate it if the devs or some other knowledgeable user would correct and/or confirm some of this stuff.
A thread in the support forum with actual discussion about dolphins inner workings? I never thought I would see the day again.
mashakos Wrote:InPCSX2, MGS3 has that same sound skipping issue when framerates go down. This is especially the case in certain areas which use framebuffer effects such as cut scenes or codec conversations (thanks Konami!!). A workaround in PCSX2 is to set the audio plugin to "Async mix". Even when framerates drop, audio runs at normal speed - as long as they don't drop to 20fps or less.
Could it be possible to implement functionality similiar to "async mix" for Dolphin's LLE recompiler maybe? This is just a shot in the dark, if one of the devs can chime in with some insight, would be great!
Dolphin and PCSX2 are in almost no way comparable. The PS2 uses an SPU and the GC/Wii uses a DSP. They are completely different architectures and completely different ways of handling audio processing. The SPU is emulated using an HLE system in PCSX2. This was likely fairly easy for them to do well compared to dolphin because of the amount of documentation available for the SPU API and more importantly the lack of different custom microcodes. The dolphin devs ran into a number of roadblocks when developing HLE emulation for the GC/Wii DSP. So they began working on an LLE system for DSP emulation instead. While LLE allows for accurate emulation of the DSP it is slow, inefficient, and does not allow features such as async mix to be implemented because it emulates the DSP at the hardware level, not the API level.
mashakos Wrote:uh, lol at your title(?) Not an encouraging statement for a developer to make!
I think the word you're looking for is "hilarious".
mashakos Wrote:hmmm, makes sense to not want to keep audio independent if it is sensitive to cpu cycles in the original hardware. Thanks for the info!
what i had in mind was not stretching but keeping audio in an independent "timer", so it keeps going at it's own normal speed, until a state change is called by the software at which the audio will be stopped swapped. The effect would similiar to this: if emulation slowed down, audio loops would be running at normal speed but might repeat more times than intended, if a state change occurs audio will switch abruptly. You see this "effect" in PCSX2, i a game is running slowly you will find that there are long pauses where BGM keeps running - then sounds start being played. Feels like the game is loading but it's just the audio running at a different speed from the rest of the emulation i.e asynchronous.
I don't think this would be possible in LLE either. Once again, very different logic systems are needed for emulating very different hardware.
Axxer Wrote:The HLE audio backend has some pretty big problems that need to be ironed out, but I don't think it's really worth the time since LLE works perfectly in almost all circumstances. The only instance I can think of where LLE might be weird has to do with some sort of "bandwidth" like thing that happens when starbit comets rain down in SMG; from what I understand the DSP gets overloaded on sound and slows down, which I don't think would happen on the Wii (I could be wrong).
Too much processing to do, it's as simple as that. When the emulated DSP is doing a lot of work it's going to take a lot of horsepower to keep it running at fullspeed.
Shonumi Wrote:I'm supposed to be working on HLE audio for the Gekko emulator (hitting some hard roadblocks yet again, kinda stuck atm). Maybe I'll make it better than Dolphin's
Hahahahaha. Unless you're god in disguise I don't see it happening.
rpglord Wrote:That functionality is already implemented in dolphin ! Its called enabling vbeam and disabling idle skipping Smile
Based on my testing,LLE audio IS running completely async to other aspect of emulation-no metter at what speed game is running,audio does not slow down.
Also,HLE seems to be async no metter what settings-I haven't noticed slowing down of audio speed or skipping with HLE with any game at any speed-which could only mean HLE is async too
If indeed HLE was "time stretching" that would mean music would slow down.
I havent noticed this,"time stretching" cant be done that good so it cant be noticed,can it ???
For example,in SMG2 if I enable 9xSSAA game will run at 20 fps,which is only 30% of speed.
Lets imagine how horible HLE audio would sound if indeed it would stretch sounds or music waiting for CPU or GPU which is running three times slower.
But,it sounds normal.
Even if sounds ( bgm ) time stretch or whatever,music tracks certanly do not
That's not the functionality that he is looking for. That's a cheap hack that barely works.
I'm pretty sure that HLE does not implement time stretching. But is does run asynchronously as you said.
Shonumi Wrote:Not exactly, but the effect is close enough for what most of want (stutterless LLE audio :3) The CPU and DSP still need to run in sync, but those options seem to affect DMA timings (e.g. how the CPU sends audio data to ARAM, which the DSP reads) to be more accurate. If the emulated CPU is still too slow, the sound stutters and "pops" even with the VBeam trick. I guess the VBeam trick makes syncing with the CPU much easier for lower-end hardware, but the GPU probably doesn't need to run quite in sync with the CPU. That's why you can still have low FPS (e.g. 45) but still get perfect audio.
Of course, now I'm talking about things I don't really know (hence it's pretty much a guess), so I'd appreciate it if the devs or some other knowledgeable user would correct and/or confirm some of this stuff.
The testing that users have done agrees with you so far.