Just in case the posts ever get deleted, they are archived below. Note that users with an asterisk at the end of their name are Dolphin emu devs or wiki/issue tracker managers.
- Part 1 - Thread on emutalk
- Part 2 - Thread on the Dolphin forums
- Part 3 - Another thread on the Dolphin forums
- Part 3.5 - Issue tracker report
- Part 4 - E-Mails to delroth
- Part 5 - More E-Mails to delroth
- Part 6 - E-Mails to JMC47
- Part 6.5 - More E-Mails to JMC47
- Part 7 - Upon finding out about this gist
- Part 8 - E-Mail to delroth
- Part 9 - Another one
I want to point out that first...I find it easier to play games using Asynchronous audio when using any emulator of consoles that used optical discs. The truth of the matter is this. The accuracy of emulation of hardware using the optical disc based media (ie CD's and DVD's and mini-DVD's...) depends upon asynchronous audio.
I have heard the excuse that since asynchronous audio has been taken away, Dolphin has become more "accurate" in emulation. This cannot be farther from the truth than saying that the grass is blue. The problem is that the GameCube used a variable bit-rate audio format rather than what normal CD's typically use (meaning CD's use the synchronous continual bit-rate format). In this case, it means that VBR formatting allowed the special effect audio to synchronize with the XFB and EFB video input and output in the console...but allowed asynchronous playing of music. This freed up a lot of computing power in the console's somewhat limited (but very powerful and extremely scalable) CPU and platform which is based around the IBM Power architecture. I do not see how it is more accurate to use synchronous audio as more accurate to the console because it is impossible to make VBR audio synchronous at all without making things skip.
If these complaints are always from the same person, why would anyone go through so much trouble to create thousands of zombie accounts to get what they want?
While the DSP was asynchronous in its own right, it ran at the same speed relative to the rest of the console. Technically, the only reason it can stall when emulated synchronously is if your system is too slow to run the emulator. Asynchronous emulation of the DSP, regardless of how well the main core keeps up, would only serve to produce uninterrupted audio, which is only slowed down in tempo.
Slowdown of the type which would ordinarily cause that to happen, or cause stutters now, would not happen with a real console. It has a tendency to cause synchronization problems, which may manifest as the games outright crashing. They were asynchronous, but not that asynchronous.
Perhaps it is time for you to upgrade your computer? After all, they did not design the Game Cube or Wii to act like it has a core CPU or GPU which is half as fast as spec, or even worse, if you cannot afford the full speed console. Some things just cannot process as fast as actual hardware in an emulator, and that causes the emulator to slow down. Introducing the variance of the DSP running full speed all the time, regardless of how slow the core is running, again, can cause games to crash, or otherwise misbehave. Are you following me?
I do follow, but I never really fully expected it to run perfectly...however...Dolphin also doesn't seem to fully utilize a computer's GPU at all. It would be nice to have a good graphics speedup utilizing that. Other than MP...the games I play work just perfectly...and while I admire the attempt at accuracy, speed is also important. If dolphin utilized the GPU a bit more (note only 10% of my GPU ever gets used using dolphin and it's not a hardware bottleneck as my PS2 and Original XBox emulation is flawless and regular gaming is freaking awesome) I'm sure it'd be perfect...but it actually doesn't. It's relying on integrated graphics or for the sake of accuracy "CPU" only. Maybe I should run my audio through my graphics card's HDMI cable to see if that does anything to redirect some sort of power...
The other thing I have noticed is that I always had crashes when using headphone jacks on my computer when when Async was being used...I started using my digital coax cable and the issue with async audio disappeared and merely slowed the tempo a bit.
It's relying on integrated graphics or for the sake of accuracy "CPU" only.
No, it's using the Intel IGP because your PC isn't configured properly. See this: http://gaming.stackexchange.com/a/72576 and select dolphin.exe.
And slightly off-topic, but could you tell me what emulator are you using to play any Xbox games in a playable state?
Dolphin also doesn't seem to fully utilize a computer's GPU at all. It would be nice to have a good graphics speedup utilizing that.
Dolphin, as any emulator need CPU power to emulate console GPU instructions. Graphic card only enhance visuals and ofc displays it on your screen. So if you want utilize your graphic card power boost up visuals with fullhd resolution, hi-res textures, filters/shaders, etc.
And slightly off-topic, but could you tell me what emulator are you using to play any Xbox games in a playable state?
Also wonder about that. AFAIK there are 3 working xb emulators, xeon, cxbx, dxbx, and none of them I would describe as good, or even able to run commercial titles without major problems.
Without async audio all AMD APU users and all mobile Intel Sandybridge users with a good GPU cannot use Dolphin anymore. While Dolphin 3.0-750 can play games like Mario Kart Wii and Xenoblade perfectly fine at good speeds, the current version only outputs garbage as audio.
If the developers would bring back a simple option to use the old audio code, the number of PCs powerful enough to work with Dolphin would be 10 times higher.
I used to actively play Zelda SS, Xenoblade Chronicles, Mariokart Wii and even Mario Galaxy on my mobile i7+GT555M and have written many bug reports, but with the current version of Dolphin my PC got tot weak to play even Gamecube games. This is just stupid and a slap in the face of most users because I am by far not the only one that has major issues with the missing async audio.
Dolphin was once a great piece of software but the current developers did a lot of harm by expelling 90% of their users with wrong design decisions, making it impossible for a normal real world PC to get audio instead of garbage.
The argument that async audio causes accuracy problems is just made up as there were no problems before and the current code enforces time stretch and async audio in a arbitrary way. Of course it also fixes some quality problems but not because it is now synchronized.
The old audio code would run as well and I see absolutely no point why they do not add a compatibility option to use the old faster code on older hardware that requires it. Especially since 90% of the gaming PCs on the world are older hardware and not even the fastest overclocked i7-Haswell is fast enough to always reach fullspeed with the new code.
And by the way I never created any zombie account anywhere.
I want to point out that this is a fairly legitimate explanation as to why Asychronous audio is very important to the platform...I find it easier to play games using Asynchronous audio when using any emulator of consoles that used optical discs. The truth of the matter is this. Accurately emulating hardware that used optical disc based media (ie CD's and DVD's and mini-DVD's...) depends upon asynchronous audio to make games playable. That was part of Nintendo's focus on the GameCube..to make a powerful, efficient, fun to play and easy to develop for console. I want to point out that this is meant as a constructive criticism and not a rant or complaint. I have many ideas as to why it seemed so buggy to use asynchronous audio. I do not mean to sound condescending as well.
I am going to be brutally honest here: It seems that people are so focused on accuracy in Dolphin 4.0's many revisions that they have lost sight on balancing accuracy with playability and speed. Constantly renaming the functions of everything does not help (more on that in a moment). I have heard the excuse that since asynchronous audio has been taken away because Asynchronous audio was buggy in the newer builds (welcome to Windows 8.1 borking everything early adopters), Dolphin has become "more accurate" in emulation towards the GameCube and Wii. This cannot be farther from the truth than saying that the grass is blue. The problem is that the GameCube and Wii both use a variable bit-rate audio format rather than what normal Audio CD's typically used (meaning Audio CD's use the synchronous continual bit-rate format). In this case, it means that VBR formatting allowed the special effects audio to synchronize with the XFB and EFB video input and output in the console...but allowed asynchronous playing of music on a separate thread. This freed up a lot of computing power requirements in the console's somewhat limited (but very powerful and extremely scalable) CPU and platform which is based around the IBM Power architecture (The very same architecture used in the Macintosh G4). I do not see how it is more accurate to use synchronous audio as more accurate to the console because it is impossible to make VBR audio synchronous at all without making things skip.
A Little history will help understand that issue I have with this: Emulating an SNES accurately requires audio synchronization with the game's localized programming because the SNES used the same exact CPU as the Apple IIgs. Part of emulating the MOS 6502CM Architecture...which could use an expansion slot (we called that the Cartridge slot on the SNES..don't believe me? How do you think it was possible to use the SuperFX chip?) to add a faster processor (TransWarp GS). The SNES was a prime example of needing asynchronous audio to match you region's TV format because if you did not get it right, audio would crackle and pop. Before the SNES, frame rates got pretty darn choppy and audio when a person used a PAL version of a game (The Megadrive/Genesis and the NES are notorious for this). Sega actually lowered the CPU clock in the Megadrive (PAL Genesis) to match timing of the PAL system, while Nintendo lowered the frame rate..play a PAL version of Kirby's Adventure o an emulator and compare it to an NTSC timed version...you will see a difference). These problems were cleared out in the Sony Playstation because of the use of VBR asynchronous audio.
Why things are so buggy and how to possible fix these issues:
-
Part of the problem is that each version of Dolphin seems to have a different standardized naming system and core for all the revisions to follow in their respective core versions. The issue is that each version ( 3.0, 3.5, 4.0) had some things moved around and renamed in the core code. Part of the code get's lost when trying to conform to new standards by renaming and rearranging things. To fix this, do not change naming standards.
-
The reason HLE DSP emulation with Asynchronous audio may have been borked has several causes. First, please take note that GameCube discs and Wii discs actually use Constant Angular Velocity to read data...This alone is the entire reason why asynchronous audio should be not only be put back in into Dolphin 4.x's core, but be on by default due to make the process accurate. I will explain the timing and several ideas on how to fix this issue in a moment. Right now I have to explain Constant Angular Velocity (CAV) and Asynchronous audio so that we are all on the same page.
CAV works in a funny way. It works by physically keeping the spindle speed at a constant rate while while the speed at which the data is written into RAM or Cache or frame buffer..constantly changes. This means that the data being output is in fact "Asynchronous" to whatever is needed at that moment in time
"Asynchronous audio" refers to the DSP reading data at a variable rate and then calculating the various write (input) speeds (rate) at which audio samples are read (output) to the internal frame buffers..Internal frames are measured in microseconds (ie...64ms for monitors using 60Hz is a great buffer size for NTSC with an internal rate of 32,090...the native internal audio sample rate of the SNES for example...is by far the best choice of getting the VPS speed of 60) in speed, and sample rate, and sending them into the frame buffer, and synchronizing them and sending them as output to be displayed by the external frame buffer. The solution is mindbogglingly simple...For each "input rate" sample of audio being generated by the GameCube, Playback Output samples should also be produced... but internally by the DSP HLE ROM. The specific internal sample rate has no baring on the external audio sample rate that we hear through our speakers as output, but it does affect timing in a huge way. If the internal sample rate is too low compared to the audio buffer in size (in ms), you get erratic frame rates and audio skipping. If it is too high, you get pops and crackles. This rate must match the timing of the VPS at all times in order to get asynchronous audio working properly and smooth frame rates.. Asynchronous audio is where the game's audio is tied to the internal input/output rate of the internal frame buffer, and synchronized to the internal speed of the console being emulated.. Simply put...Fixed audio timing (synchronous audio timing) is not the same as synchronizing a game using audio (asynchronous audio). Maybe we should add controls to the DSP section that allow one to control the internal sample rate with a slider and allow one to control frame buffer sizes like the ones in current builds of SNES9x. While in the core properties add a function to disable "fixed audio timing" and options to enable (Sync Using Audio) like we see in the specific ROM settings in Project64.
The point to this mess of a post I make is this....The use of Asynchronous audio is important to accuracy because that is how discs made using Constant Angular Velocity must function in order to read any data off the disc. All CD players use a sort of buffer between what is being read and what is being put out for us to hear. The CAV standard merely reads data inconsistently. Because Asynchronous audio is inconsistent to the buffering of audio data and synchronized to the input rate, logic suggests that the two act the same. We physically see the disc being spun at a constant rate using CAV, but the data is read from the disc in an inconsistent manner. Similarly, with Asynchronous audio we physically hear consistent streaming of audio...but that audio written as input from the console is read inconsistently.
hah.
You clearly have no idea what you're talking about and I'm not even sure why I'm wasting my time replying to such a mess of backseat programming based on no factual information. But here we go.
I want to point out that this is a fairly legitimate explanation as to why Asychronous audio is very important to the platform...I find it easier to play games using Asynchronous audio when using any emulator of consoles that used optical discs. The truth of the matter is this. Accurately emulating hardware that used optical disc based media (ie CD's and DVD's and mini-DVD's...) depends upon asynchronous audio to make games playable. That was part of Nintendo's focus on the GameCube..to make a powerful, efficient, fun to play and easy to develop for console. I want to point out that this is meant as a constructive criticism and not a rant or complaint. I have many ideas as to why it seemed so buggy to use asynchronous audio. I do not mean to sound condescending as well.
See, this is already starting so badly. How do optical medias have anything to do with DSP emulation timeslices? DSP processing is done exclusively from RAM to RAM with no involvement of any other form of data storage.
I am going to be brutally honest here: It seems that people are so focused on accuracy in Dolphin 4.0's many revisions that they have lost sight on balancing accuracy with playability and speed.
No we haven't, and I think the tradeoffs we've been doing have been pretty good. Case in point:
- Several games that required the software renderer to work properly can now work with hardware rendering.
- Several games that required DSPLLE to run without regular freezes can now run with DSPHLE and work on computers two generations older.
- CPU requirements actually mostly went down since the release of Dolphin 4.0.
Constantly renaming the functions of everything does not help (more on that in a moment).
I have no idea what you are talking about. Like, really.
I have heard the excuse that since asynchronous audio has been taken away because Asynchronous audio was buggy in the newer builds (welcome to Windows 8.1 borking everything early adopters)
Operating systems have nothing to do with this.
Dolphin has become "more accurate" in emulation towards the GameCube and Wii.
It has, read:
- http://blog.lse.epita.fr/articles/38-emulating-the-gamecube-audio-processing-in-dolphin.html
- http://blog.delroth.net/2013/07/why-dolphin-is-getting-rid-of-asynchronous-audio-processing/
This cannot be farther from the truth than saying that the grass is blue. The problem is that the GameCube and Wii both use a variable bit-rate audio format
That is not true, the GameCube and Wii DSP handle 3 different audio formats: PCM8, PCM16, ADPCM16. These three formats have a fixed bitrate.
rather than what normal Audio CD's typically used (meaning Audio CD's use the synchronous continual bit-rate format). In this case, it means that VBR formatting allowed the special effects audio to synchronize with the XFB and EFB video input and output in the console...but allowed asynchronous playing of music on a separate thread. This freed up a lot of computing power requirements in the console's somewhat limited (but very powerful and extremely scalable) CPU and platform which is based around the IBM Power architecture (The very same architecture used in the Macintosh G4). I do not see how it is more accurate to use synchronous audio as more accurate to the console because it is impossible to make VBR audio synchronous at all without making things skip.
I started replying to that point by point but it's just so wrong I'll just abort and laugh at it.
A Little history will help understand that issue I have with this: Emulating an SNES accurately requires audio synchronization with the game's localized programming because the SNES used the same exact CPU as the Apple IIgs. Part of emulating the MOS 6502CM Architecture...which could use an expansion slot (we called that the Cartridge slot on the SNES..don't believe me? How do you think it was possible to use the SuperFX chip?) to add a faster processor (TransWarp GS). The SNES was a prime example of needing asynchronous audio to match you region's TV format because if you did not get it right, audio would crackle and pop. Before the SNES, frame rates got pretty darn choppy and audio when a person used a PAL version of a game (The Megadrive/Genesis and the NES are notorious for this). Sega actually lowered the CPU clock in the Megadrive (PAL Genesis) to match timing of the PAL system, while Nintendo lowered the frame rate..play a PAL version of Kirby's Adventure o an emulator and compare it to an NTSC timed version...you will see a difference). These problems were cleared out in the Sony Playstation because of the use of VBR asynchronous audio.
Cool, this has nothing to do with Dolphin at all.
Why things are so buggy and how to possible fix these issues:
1. Part of the problem is that each version of Dolphin seems to have a different standardized naming system and core for all >the revisions to follow in their respective core versions. The issue is that each version ( 3.0, 3.5, 4.0) had some things >moved around and renamed in the core code. Part of the code get's lost when trying to conform to new standards by renaming and >rearranging things. To fix this, do not change naming standards.
Oh god, the code is changing! Stop changing the code, it will solve all problems!
You are an idiot.
2. The reason HLE DSP emulation with Asynchronous audio may have been borked has several causes. First, please take note that GameCube discs and Wii discs actually use Constant Angular Velocity to read data...This alone is the entire reason why asynchronous audio should be not only be put back in into Dolphin 4.x's core, but be on by default due to make the process accurate. I will explain the timing and several ideas on how to fix this issue in a moment. Right now I have to explain Constant Angular Velocity (CAV) and Asynchronous audio so that we are all on the same page.
CAV works in a funny way. It works by physically keeping the spindle speed at a constant rate while while the speed at which the data is written into RAM or Cache or frame buffer..constantly changes. This means that the data being output is in fact "Asynchronous" to whatever is needed at that moment in ticme.
Blablabla irrelevant bullshit (that is also not true, but who cares).
"Asynchronous audio" refers to the DSP reading data at a variable rate
Oh god, that's almost right!
and then calculating the various write (input) speeds (rate) at which audio samples are read (output) to the internal frame buffers.
Welp, so much for being right.
Internal frames are measured in microseconds (ie...64ms for monitors using 60Hz is a great buffer size for NTSC with an internal rate of 32,090...the native internal audio sample rate of the SNES for example...is by far the best choice of getting the VPS speed of 60) in speed, and sample rate, and sending them into the frame buffer, and synchronizing them and sending them as output to be displayed by the external frame buffer.
There is no notion of "internal frames" for audio in a generic way on GameCube. The DSP is a programmable CPU which runs audio emulation code provided by the game. In practice, there are 3 variants of audio emulation code: AX, AXWii, Zelda. AX uses 5ms internal frames, AXWii uses 3ms internal frames, Zelda uses 5ms internal frames. We do not get to choose that.
The solution is mindbogglingly simple...For each "input rate" sample of audio being generated by the GameCube, Playback Output samples should also be produced... but internally by the DSP HLE ROM.
This breaks because audio data goes back and forth between CPU and DSP sometimes 2 to 3 times. You cannot have larger "internal" HLE buffers if you want to keep this behavior, which is required for a lot of sound effects.
The specific internal sample rate has no baring on the external audio sample rate that we hear through our speakers as output, but it does affect timing in a huge way. If the internal sample rate is too low compared to the audio buffer in size (in ms), you get erratic frame rates and audio skipping. If it is too high, you get pops and crackles. This rate must match the timing of the VPS at all times in order to get asynchronous audio working properly and smooth frame rates.. Asynchronous audio is where the game's audio is tied to the internal input/output rate of the internal frame buffer, and synchronized to the internal speed of the console being emulated.. Simply put...Fixed audio timing (synchronous audio timing) is not the same as synchronizing a game using audio (asynchronous audio). Maybe we should add controls to the DSP section that allow one to control the internal sample rate with a slider and allow one to control frame buffer sizes like the ones in current builds of SNES9x. While in the core properties add a function to disable "fixed audio timing" and options to enable (Sync Using Audio) like we see in the specific ROM settings in Project64.
Wrong in too many ways to try and explain, sorry.
The point to this mess of a post I make is this....The use of Asynchronous audio is important to accuracy because that is how discs made using Constant Angular Velocity must function in order to read any data off the disc. All CD players use a sort of buffer between what is being read and what is being put out for us to hear. The CAV standard merely reads data inconsistently. Because Asynchronous audio is inconsistent to the buffering of audio data and synchronized to the input rate, logic suggests that the two act the same. We physically see the disc being spun at a constant rate using CAV, but the data is read from the disc in an inconsistent manner. Similarly, with Asynchronous audio we physically hear consistent streaming of audio...but that audio written as input from the console is read inconsistently.
The point I'm trying to make is that you have no idea what you are talking about and you should avoid trying to teach us how to do our job. Go fork the project if you are not happy about the direction in which we're going.
Let's play a little game: if your next post contains any factual mistake regarding how GameCube DSP audio processing works, I'll just ban you without even bothering to reply.
The one thing I'd like to know, is that with all the data and documentation available for the GameCube and Wii, that all the reverse engineering, testing, and everything, how exactly did OP manage to come up with this conclusion.
No need to be rude. I should inform you that I do have Asperger's Syndrome and I am the type that sometimes over-explains things quite often. I admit to knowing nothing about how the DSP works...but I do know that for some reason that without Asynchronous audio...minor FPS count drops cause the audio to stutter almost instantly when playing games that lock that FPS count and VPS count together (yes I do see the VPS count in the Title bar of the games I run). I don't know why it does
I believe you were the rude one waltzing in here saying that you knew exactly what was wrong without knowing a lick about the DSP. Seriously, if you're going to "overexplain" something, at least understand the bare basics of what you're explaining.
When the game slows down, ever, because Dolphin is an emulator, emulation slows down. Synchronous audio makes it so that this slowdown will break up the audio. That is why.
So many completely incorrect assumptions, I don't even know where to begin. I can only say that if you'd actually paid some real amount of attention to the changes in the DSP code (in addition to knowing anything about how the DSP worked), you wouldn't have come to any of these insane conclusions. Comparing everything to how other consoles work is also mostly invalid – very little logic is universally applicable when it comes to the low-level details of video game console hardware.
I especially enjoyed the "do not change naming standards" part, that's like living in a house for a decade and shitting on the floor everywhere and never cleaning anything up. It makes life much harder and you're liable to get some sort of medical condition from it. Code cleanup is a vital part of development, you can't leave ugly code lying around.
I believe you were the rude one waltzing in here saying that you knew exactly what was wrong without knowing a lick about the DSP. Seriously, if you're going to "overexplain" something, at least understand the bare basics of what you're explaining.
I admit to and apologize for being rude. I do not ever mean to be. I will shorten everything by turning it into a question...
Why can't someone maybe submit a revision that adds a functional check box to the DSP menu or the game specific core (game properties) properties menu to enable or disable asynchronous audio? That way certain users can turn it off..while certain other users who are having issues can turn it on.
Yeah, I think the OP got the point, so everyone may stop bullying someone who tried to bring up a topic he deemed important. I'll delete and warn off any following posts like that.
I admit to and apologize for being rude. I do not ever mean to be. I will shorten everything by turning it into a question...
Why can't someone maybe submit a revision that adds a functional check box to the DSP menu or the game specific core (game properties) properties menu to enable or disable asynchronous audio? That way certain users can turn it off..while certain other users who are having issues can turn it on.
People are rude/impatient/annoyed about this topic because it has been discussed for ages. Articles have been written about why this is impossible and never going to happen and why synchronous audio processing is the way to go.
But I'll reply to that one more time: why can't we have a check box sync/async? Because async audio processing breaks too many things to be worth it in our opinion. It's not just games freezing, having missing samples and missing FX (reverb/...), it's also a ton of crappy code that makes it harder to improve Dolphin. Removing asynchronous audio processing completely allowed us to remove whole chunks of code that nobody wanted to maintain.
If you disagree, stop complaining and code your own fork. If async audio processing is worth more to users than the improvement we can provide by not having async audio processing (for example, having a working Zelda HLE UCode, as opposed to something causing random freezes/crashes and requiring people to use DSPLLE), I'm sure users will start using your fork. My guess is that being able to finally play SMG2 without missing music / freezes with DSPHLE is more useful, on top of being more accurate emulation.
I've been playing through Mario Galaxy for the first time on Dolphin on my PC thanks to the audio not being completely busted. The reason the audio isn't totally busted is because it's actually synchronized with what the game is expecting. If the Wii/GC were to actually slow down, do you think it'd be able to process the music (there are times when the GPU in the Wii/GC slows down, where VPS is unaffected, but Dolphin does that too as well; you won't see the music slowdown during those times) at the same speed? It wouldn't, hypothetically, but some games may code around it, etc. We'll just assume it would for the example game.
Asynchronous audio simply isn't an option for those games because it caused them to break. And for the Zelda ucode games, this isn't changes that were done over years, or forgotten code (in fact, it was ignored because audio is such a headache); all the changes to make it synchronous were done in the last week! And it was done so because it improved emulation. Whether or not it improves your particular experience on certain games, that doesn't matter. If the old broken audio implementation managed to make your experience better in certain games, use those old builds with those games, but don't come complaining when it doesn't work with half your library, or the game crashes, or you run into a multitude of other problems.
I'm not the most technical guy, and I certainly do see the appeal of asynchronous audio (Hell, it was one of the reasons I was able to have such a good experience playing Mario Kart Wii at school on my laptop with friends) but I sure as hell won't argue that it's better for the emulator.
It should probably be explained to the op how much work actually went into emulating the dsp and audio in Dolphin due to the lack of documentation in the beginning. If it wasn't for the Dolphin team and a lot of reverse engineering Zelda Ucode games such as Zelda: Windwaker, Twilight Princess, Super Mario games etc.. would have never had audio. Not only that many other games wouldn't have proper audio under HLE and there would be several other issues among those already mentioned above.
People are rude/impatient/annoyed about this topic because it has been discussed for ages. Articles have been written about why this is impossible and never going to happen and why synchronous audio processing is the way to go.
But I'll reply to that one more time: why can't we have a check box sync/async? Because async audio processing breaks too many things to be worth it in our opinion. It's not just games freezing, having missing samples and missing FX (reverb/...), it's also a ton of crappy code that makes it harder to improve Dolphin. Removing asynchronous audio processing completely allowed us to remove whole chunks of code that nobody wanted to maintain.
If you disagree, stop complaining and code your own fork. If async audio processing is worth more to users than the improvement we can provide by not having async audio processing (for example, having a working Zelda HLE UCode, as opposed to something causing random freezes/crashes and requiring people to use DSPLLE), I'm sure users will start using your fork. My guess is that being able to finally play SMG2 without missing music / freezes with DSPHLE is more useful, on top of being more accurate emulation.
I do understand that point...problem with crappy code is that you need someone to try to organize it....I like the openness that the development of Dolphin has provided because it allows people like me to figure out which revisions work best for Windows users...But from what I can see on the download page, it has become very difficult it seems to sort that wheat from the chaff. Some users devloping Dolphin are using Linux based OS's to compile or "fork" the code into MS VBS 2013...The Linux versions of that (notable complaint from Gabe Newel about MS VB2013) lacks certain features that MS deems "exclusive" to the Microsoft software line. This leaves Linux devs out to dry on developing around a few key features which include but are not limited to such as sufficient programming Asynchronous audio in the Direct Sound API and of course proprietary use of XAudio. They have also phased out DirectX 9 in VB2013...deeming it "too old" yet the previous version of VBS is the single most widely used development tool for PC gaming and emulation development.
With respect..what "improvement" is there exactly when a frame rate drops and the frame advance on the audio gets muted? From my own observastion Asycn works best with digital output of audio...I use 5.1 surround sound on a digital coax cable. This issue seems to be an OS based issue at large...which would likely be able to be solved by including that part of the code from Dolphin 3.5's HLE and simply making a check box option for async audio rather than simply removing it. The issue is optimization, not accuracy.
Note that Linux uses OpenAL and OpenAL works rather differently from Direct3D Audio and Xaudio...It could be a kink in the newest version of MS VBS too where Windows users get those development features exclusively...I don't know...but for now, the only solution I see to this is simply making it optional for the user to use async audio.
The improvement is that audio works correctly instead of being some guessed, half assed, improper way. The emulator's first and foremost job is the emulate the console PROPERLY.
Async audio isn't that bad imo. It solves "some" issues, but not the ones everybody loved. In short, async audio allows us to look a bit into the future. So we could ignore the emulation time variance and stream the audio on real time which reduces the latency a bit.
But the average emulation time should be the real time, else the music stops long before the game expect the music to finish. Just search on the issue tracker for music stopping issues. So it can't be used to get smooth audio for non 100% emulation speed, but it would allow us to generate some ms of audio and to stretch further on (sync audio will increase the latency much more with smooth stretching).
We also have to care to not underrun the emulated fifo. As the emulation if often blocked for >200ms in cut scenes, we have to block the audio, so there will always be stutters (or crashes, which one is better?)
quotes degasus
One thing I just realized...when I use Async audio wearing my headphones connected to my conputer's headphone jacks...I do get crashes...I use an RCA digital coaxial cable on my 5.1 stereo receiver and and no crash. So it solves issues for some games but not all...Why not then simply add a ticker to the "Game Properties" window in the "Core" box that allows you to use the old Dolphin 3.5 sound engine? This makes it game specific and doesn't have to be implemented universally in the DSP menu. I would hazard a guess that since headphone jacks are mostly analog by nature and that data has to run through a DAC to provide sound to a pair of headphones, that most of the non-game related crashes happen due to DAC conversion issues.
I haven't emulated many GC games outside of Paper Mario, Zelda Windwaker, Metroid Prime, and Soul Calibur II...MP is the only game the severely frame drops for me...
Have you tried using Monster cables?
quotes shuffle2
Have you tried something that's actually worth what it costs? An inspection of many of their XLR cables reveal that the metalworking is very bubbly. Far too bubbly for any sort of electrical cable heads, especially those that carry analog signals.
EDIT: Do not bring up how RCA and XLR are different standards. One type of cable being wrong points to the company doing the rest wrong.
EDIT MORE: My samples might have been tampered with or bad; I did a quick google search and see no such thing thus far. Will not remove post over this; sometimes google's a filthy, money-covered liar.
EDIT EVEN MORE: Bad/tampered samples; the only crap that I'm seeing is that they're all that crappy gold-plated stuff that costs more and sounds worse, when a high-quality cable is nickle or silver plated and doesn't cost twice as much for 10' as their nearest competitors asks for 20'.*
But, crashing when you plug in your headphones has absolutely nothing to do with DAC issues. The product of DAC issues would be garbled audio. Also, DAC issues would only happen when plugging in headphones if you're switching between a digital and analog connection, like S/PDIF to 3.5mm phone. RCA is analog, unless you are running an audio studio computer, which I would doubt, considering your level of knowledge on these subjects. Actually, just realized that he might be referring to the usage of an RCA cable for coaxial S/PDIF.
- = slight exaggeration
quotes kinkinkijkin
Sarcasm is hard to catch on the internet. Should have used a master ball.
>people actually using Monster's cables
I'd better get out of this thread before it gives me hemorrhoids.
quotes Sonicadvance1
There are a few symbols that can be used to denote sarcasm, you know.
quotes kinkinkijikin's post to shuffle2
"Actually, just realized that he might be referring to the usage of an RCA cable for coaxial S/PDIF."
Bingo. I grew up around chemistry and metallurgy long enough to know that Monster is full of crap. I am using an S/PDIF digital coaxial cable on my audio connection from my PC to the Stereo Receiver...Part of the stuttering is garbled audio when using a normal 3.5mm headphone jack to connect your speakers or headphones. My guess is that he audio timing is different and my buffer length often has to be set to 64ms in order to compensate for garbled sound when using Asynchronous audio. The reason I do this is because I also use ePSXe to play Final Fantasy 9 and Chrono Cross..two games that take advantage of Sony's DSP capabilities. Without async audio, I get sudden bursts of very loud garbled static as if lighting had somehow struck my speakers. My PC is fully capable of using DTS standard and Dolby Digital 7.1 surround sound without prologic or neo6 if i have it connected to the S/PDIF or HDMI Audio receivers.
Sounds more like an issue with your audio device. If you're using the audio device built in to the motherboard, this would make sense. They tend to be pretty bad, unless liberated by the digital connection. Personally, my motherboard outputs audio at an extremely low volume, and I have to pass it through a makeshift amp (because I don't have a real one at home), and the audio that comes out is also pretty dirty, and occasionally lets out a great crackle that would kill most professional hardware that isn't properly protected, and the ears of people using said professional hardware. To the point that it's wrecking my non-professional, properly-protected hardware rather quickly. So, I wouldn't be surprised if this is a motherboard sound issue.
quotes kinkinkijikin
Can't afford a sound card...The problem does go away with a digital connection :-3 maybe I should run my audio settings through my GTX550ti.
Or you should get a sound system with an optional redirect to headphones. Normally, if audio goes through HDMI, it was still sent through the motherboard audio device. Now, iirc, HDMI is digital audio anyways, so it would have the chance of alleviating your problem, but it can sometimes be more expensive to redirect HDMI audio without invoking the wrath of HDCP than getting a soundcard/replacing your digital audio controller, all of which is less expensive than running down your only audio hardware that you have at home because you're too lazy to do anything about it (my situation). Then again, if you have a screen/TV with a headphone jack, it's entirely okay.
quotes kinkinkjikin
I have my rig hooked up to a 42 inch Toshiba TV set. "Game Mode" eliminates input lag. I think I'll keep using the current S/PDIF connection until I can afford an audio card. Always helpful to know all this.
HDCP isn't lag. HDCP is stream protection. It's extremely annoying, is part of the HDMI standard (and a few others), and is practically useless for what it's made to do.
quotes Wally123
You best off getting an A/V Receiver rather then a sound card .
quotes Gir
My PC's audio device...is integrated...My stereo reciever is not the issue. My PC's integrated audio (unfortunately no RealTek) is not the best it could be...Even when I do get decent frame rates, in Dolphin 4.x...I get that odd sudden spike in volume from time to time...and I have my suspicions it's the emulator...Even if I decided to turn off async audio in 3.5...I didn't have that problem.
However...I do realize I need a decent sound card...I need that regardless to aleviate my CPU from that burden. I do not have integrated graphics...
quotes Wally123
No need to be rude. I should inform you that I do have Asperger's Syndrome and I am the type that sometimes over-explains things quite often.
Never, ever, use a disability as an excuse. Ever.
quotes mudlord
Not really meant as one but duly noted...won't happen again...and my only question to you now is this...Are you the very same mudlord who worked on RiceVideo for N64 for a while?
Wally, I'm gonna level with you here, but it requires you to come to terms with a few things first. I'm not saying you have to, and I don't want you to lie and say you agree if you don't.
1: Your first post in this thread is full of buzzwords, bullshit and absolute insanity.
Now, I don't think you're an unintelligent person, you write in complete sentences with proper grammar which puts you above a lot of people in the world. I don't know why you went through so much effort to try and prove a point, but you missed the mark completely. Whether you knew it at the time, or were just in over your head with stuff you didn't understand, the first post of this thread has no real value in the conversation.
2: Asynchronous audio is less accurate
You need to understand that you're not asking for them to increase accuracy, that's where you went wrong. You got it into your head somehow through very convoluted means that asynchronous = more accurate. It doesn't. Don't try to argue it, we already know the truth. The thing is, you don't need to argue that it's more accurate. There is a counter argument against it that doesn't involve bullshitting around.
3: You're asking for a very hard to implement feature.
The old asynchronous audio is full of hacks to make it work; and causes ton of game issues, while accurate audio emulation works just by doing what it's supposed to do. Simply putting an option in for the old code would cause months of work, cause tons of headaches and problems for developers, and make it harder to improve the good audio emulation. Do you really think they're that unreasonable? That if they could just plug in the old code without any repercussions and give users a choice, they wouldn't to spite the users?
4: Asynchronous audio does have userside benefits
Developers get little/no benefit for having asynchronous audio. They're making the emulator to emulate the games, for the most part they're not in it to play video games at full speed. That being said, some people are okay with a game not running full speed as long as they still get a good experience. Audio is part of the experience. Delroth has said before and will probably say again that if someone made an asynchronous HLE option that met Dolphin's coding standards that there would be no issue merging it. It's just that doing it is a ton of work, it has absolutely no benefits to the quality of emulation, and will likely cause problems down the road when the proper audio gets upgrades.
5: Users have a limited perspective.
Sometimes users don't know what's good for them as well. Asynchronous audio caused problems in literally hundreds of games, crashes, no audio, broken audio, hangs, and music freezes. Heck, look at Mario Galaxy 1/2 up until Zelda HLE was synchronous. You either dealt with the hangs and couldn't beat the game (easily) or used the LLE plugin which is a multitude slower and even I can't get running full speed on a fairly modern computer. Thanks to having an ACCURATE HLE option, now I can play the game just fine. For many years, these games were basically unplayable in HLE due to being left behind due to how hard it would be to update the code and make it more accurate.
Users asking for asynchronous audio don't realize that it means not being able to trust HLE audio again. It took me months to realize just how great it was to have, just how bad the old way of handling audio was. Can it be better? Probably. Can it be perfect and trustable to always work? Doubtful. Games rely on audio being synchronous for the timings of events. Without those timings being synced to what the game expects, there will always be a risk of a game suddenly crashing with no recourse.
That's my thoughts on it, at least. I hope this helps you see more of what I'm seeing in this particular situation. And why the reaction was so livid from the Dolphin familiars.
quotes mudlord
Sorry to interject on this, but his post is practically a copy/paste of practically everyone else on the internet I've met with aspergers. Hell, I almost wrote something like that myself one time.* It's not really a disability, either. It just makes social interaction without making someone want to kill you a lot harder.
But, as I've said to everyone else who said this stuff, it's not really an excuse. If someone as dull-witted as myself can power through it*, I'm pretty sure you can as well.
- = I'm sure SOMEONE out there realized that I might be some sort of autist by now, really. Actually, I might have pulled the "I have asperger's" line here; there are a few moments I remember "almost" posting that, and then, when I look back, I actually DID post it.
quotes JMC47
I see your point. And I am glad you gave me a respectful answer. I do have a couple of ideas if you'll hear me out. This is purely hypothetical...but say we do implement the asynchronous option as game specific (in Game Properties "core" box) to speed up some games...would it be possible to to implement some sort of CPU wait (as in for the computer...not the console) to sync with the audio as that seems to help certain audio plugins for ePSXe?
Another idea I have, and this is outside of async/sync audio, is that what if someone added a graphics , fps limiter, and DSP menu to the game properties window? It would make it easier to use different specific settings for different games. Just add a couple of tabs to the game properties menu.
"Implementing" async audio as a game properties option does absolutely nothing different for the underlying code. All it does is slightly change where it appears for the users, and how they'd enable it; everything else would be all but unchanged. It doesn't make it easier or feasible for the developers to implement. Since UI stuff is trivial compared to the actual implementation, I don't think this is really going to help your argument at all.
You'd have to ask someone else about the CPU wait thing; it's probably not feasible, but I'm not a programmer that really understands how the CPU emulation here works. I don't think you can just tell the CPU to wait and not expect to break things, but someone more knowledgeable than me would need to answer.
The last point about adding stuff to the game properties window gets more into Dolphin's UI a bit, and is mostly unrelated to the main issue at hand.
This CPU wait is here called "throttle by audio", just select audio as framelimiter.
quotes neobrain Yeah, I think the OP got the point, so everyone may stop bullying someone who tried to bring up a topic he deemed important. I'll delete and warn off any following posts like that.
Bullying?
You've got to admit anyone who posts that much nonsense in one post, implies it's all factual, and does zero research on any of it is basically openly inviting themselves to be rediculed by the community at large. I mean he got DELROTH of all people to post the kind of WoT posts you normally see me doing. That means he must have generated some serious rage. Hell there are still large portions of nonsense in his post that nobody has gone over yet.
quotes kinkinkijikin But, crashing when you plug in your headphones has absolutely nothing to do with DAC issues. The product of DAC issues would be garbled audio. Also, DAC issues would only happen when plugging in headphones if you're switching between a digital and analog connection, like S/PDIF to 3.5mm phone. RCA is analog, unless you are running an audio studio computer, which I would doubt, considering your level of knowledge on these subjects.
That's actually mostly correct even though you crossed it out. His issue is most likely with his audio drivers. I can't be sure since he has given us zero information about it.
quotes kinkinkijikin Or you should get a sound system with an optional redirect to headphones. Normally, if audio goes through HDMI, it was still sent through the motherboard audio device. Now, iirc, HDMI is digital audio anyways, so it would have the chance of alleviating your problem, but it can sometimes be more expensive to redirect HDMI audio without invoking the wrath of HDCP than getting a soundcard/replacing your digital audio controller, all of which is less expensive than running down your only audio hardware that you have at home because you're too lazy to do anything about it (my situation). Then again, if you have a screen/TV with a headphone jack, it's entirely okay.
If audio goes through HDMI it doesn't touch the motherboards audio circuits at all. The data is copied by the drivers from RAM into a buffer in or near the GPU and then from there streamed over HDMI.
He should be running all of his audio through a digital connection (coaxial spdif, optical spdif, or hdmi) to his receiver. Assuming his stereo receiver has a headphone port (almost all of them do) he should be plugging his headphones into that instead of the PC. If he continues to use the A/V receiver getting a proper audio card would do little to improve his system.
quotes Wally123 However...I do realize I need a decent sound card...I need that regardless to aleviate my CPU from that burden. I do not have integrated graphics...
No you don't. Your integrated audio uses little to no cpu resources and hardware accelerated audio has been dead for almost a decade now.
Are you the very same mudlord who worked on RiceVideo for N64 for a while?
Yes he is
quotes kinkinkijikin Sorry to interject on this, but his post is practically a copy/paste of practically everyone else on the internet I've met with aspergers. Hell, I almost wrote something like that myself one time.* It's not really a disability, either. It just makes social interaction without making someone want to kill you a lot harder.
But, as I've said to everyone else who said this stuff, it's not really an excuse. If someone as dull-witted as myself can power through it*, I'm pretty sure you can as well.
- = I'm sure SOMEONE out there realized that I might be some sort of autist by now, really. Actually, I might have pulled the "I have asperger's" line here; there are a few moments I remember "almost" posting that, and then, when I look back, I actually DID post it.
I know at least 2 other regulars here that have it too (I won't name names for obvious reasons) and they manage just fine. And because it can be managed (although not completely cured) through medication and self control that's why people tend to frown on others using it as an excuse for things (this thread being a perfect example).
I crossed it out because I hadn't taken into account that by "RCA" he might be referring to S/PDIF coaxial, as I already said, which would mean that he WOULD be switching from a digital to audio connection, a thing that I said would be the only case in which he'd be right about it being the DAC. It wouldn't really surprise me if it were the DAC either, onboard audio solutions are all delicate and crappy, with very, very few exceptions
And, since I don't work with the micro/software side of audio, I didn't actually know that about HDMI. Though, he would be helped by a new soundcard if he also has S/PDIF optical inputs on his stereo receiver, since optical S/PDIF is superior to (if only more fragile than) coaxial S/PDIF. The thing is, though, optical cables cannot be bent too much or they will snap and become useless.
Also, Creative still releases audio cards with hardware acceleration for some features of OpenAL, and only when it's through OpenAL. It's almost like they technically own the rights to OpenAL.
Fixed something...or at least found a revision that works flawlessly in audio for Metroid prime...4.0-1340...I set my DSP setting to XAudio and then in the game's properties I unticked "Synchronize GPU Thread"..and this is under Direct3D for video...
So using the latest builds works fine for you? Also, Sync GPU is only used with Metroid Prime 3 and Trilogy, it won't affect 1/2.
all the following quotes are quoting kinkinkijikin
I crossed it out because I hadn't taken into account that by "RCA" he might be referring to S/PDIF coaxial, as I already said,
This week in "how consumers ruin terminology", the story of RCA.
RCA is actually the name for a company. Radio corportation of america. A very large american company that was involved with pretty much anything to do with radio electronics back in the day. Since their equipment was so popular in the industry the cables they used quickly became the standard. The term "RCA" started being widely used to describe the most common connector used on their equipment. Since apparently everyone was too lazy to invent a proper term for it and just decided to name it after the company that invented it instead. Later on people began referring to any cable that uses this connector as an "RCA cable" since originally there was only one standard cable (now there are many, and we still haven't managed to start using terms to distinguish between them). Once consumers start using a specific term to refer to specific products companies are forced to sell and market the products using that name so people can easily identify them. Thus we're now stuck with everybody using this confusing and downright incorrect system of terminology.
Subwoofer cables, rca audio cables, composite video cables, component video cables, spdif coaxial cables, and so on can all be referred to as "RCA cables". Stupid isn't it?
which would mean that he WOULD be switching from a digital to audio connection,
Switching from a digital connection to an audio connection.... One day I'm going to get you to write a post that makes sense, one day.
a thing that I said would be the only case in which he'd be right about it being the DAC. It wouldn't really surprise me if it were the DAC either, onboard audio solutions are all delicate and crappy, with very, very few exceptions
I don't see how a DAC crashing an application would even be possible.
And, since I don't work with the micro/software side of audio, I didn't actually know that about HDMI. Though, he would be helped by a new soundcard if he also has S/PDIF optical inputs on his stereo receiver, since optical S/PDIF is superior to (if only more fragile than) coaxial S/PDIF. The thing is, though, optical cables cannot be bent too much or they will snap and become useless.
Optical cables provide no improvement in audio quality assuming the same settings are used. And you don't need to work with the "micro/software side of audio" (whatever that means) to recognize that HDMI is a digital A/V connection and therefore doesn't involve your systems analog audio circuits.
Also, Creative still releases audio cards with hardware acceleration for some features of OpenAL, and only when it's through OpenAL. It's almost like they technically own the rights to OpenAL.
Yeah, and they're useless. There are maybe a few games in existance that can make use of these features and none of them are demanding enough to actually get any speedup from it (they're all older games). They can only accelerate a limited number of functions in certain extensions to the API and only if they're used a specific way. These days everything these cards can do can be done just as fast in software (CPU based) without all of the restrictions put in place by hardware based solutions. Which is why devs have abandoned it. There is simply no point in hardware accelerated audio anymore. In fact it's often slower than software based solutions these days. It's not like 3D rendering where GPUs are dramatically faster at performing the task at hand than CPUs and we actually need that extra speed to do things that wouldn't otherwise be possible to do.
I meant to write analog, on that second one.
And the third one is product of forgetting what the conversation was about.
Fourth, signal quality differs over distances of cable. Optical cables are far better for keeping high-quality signal than electrical cables, enough so that 20' optical cable can be the quality of 5' of electrical cable. The receiving end therefore has to do less guesswork (if it does any at all, if it doesn't then it just sounds worse), meaning that the original audio is better-maintained. Also, optical cables look cooler when the sleeving's taken off than electrical cables do.
You kind of need to make the cable a good 20m long before the electrical one will have noticeable signal degradation when it's a digital signal, though. There needs to be an awful amount of interference to make a 0 look like a 1.
@kinkin None of that makes any sense.
Digital audio transmission either works or it doesn't. There is no gradual loss of quality over long distances as with analog transmission. Once you reach a certain point it just stops working. Or in the rare case it "thinks" it's working and all you hear is extremely fucked up random static. And there is no "guesswork" involved other than parity.
The max distance at which this happens in the case of spdif: -is so high that home users would never run into it -is mostly dependant on the quality of the cable, not the type -is generally higher with coaxial, not optical. The LEDs and thin plastic fiber used by optical spdif typically cut out after about 10-20 meters whereas good coax can go 30+. -generally can't be reached unless you chain multiple cables together without a repeater since pretty much all cables are capable of transmitting their full distance (obviously)
Some audiophiles have suggested that optical produces inferior audio quality due to the additional clock jitter but there isn't much evidence to back this up.
Pros of optical: -higher max bandwidth when using high quality cables which enables higher bitrate audio modes (OP is unlikely to make use of any of these assuming his receiver even supports them, it could be useful for someone trying to run uncompressed surround sound though) -can be used in environments with strong RF interference (unless you plan on having the cable near a big power transformer I don't see this being an issue) -no potential for ground loops (only an issue for stupid people)
Pros of coax -higher max distance -no signaling issues with cables being crushed or bent -more flexible and durable cables -less clock jitter in some equipment
Price is also mostly determined by the quality of the cable, not the type. Most people just use whichever one their equipment supports (usually optical) since most A/V equipment supports one or the other, not both.
Edit: To clarify. This is because digital signals are virtually immune to RF interference and generally have built in error checking systems that reject corrupt data. The cables max length is based not on interference but rather at what point the power losses become so high that not enough electricity/light makes it through to the other end to register as a 1. This is the same to some degree with analog transmission but with analog the quality of the signal is also affected by distance since longer distances = more time to absorb interference.
lol, audio is just pulsed DC. There is no need to think about any HF issue
quotes JMC47
I sort of noticed it's on by default by the emulator..I've had to untick GPU Sync for every game. The only DSP backend that works properly for now is Xaudio.
This thread should probably be moved to another section such as general discussion. I would move it but I'm not sure if it was left here for a reason or if other staff haven't bothered moving this thre
Blue box != ticked. Just means it'll use the emulator default. Checked means it'll override and always enabled, unchecked means it'll override and always be off.
In most games, you're likely just seeing a placebo effect.
quotes Xtreme2damax
Revision 4.0-1341 got rid of the crackling I mentioned that the Xaudio and DirectSound backends were having. I also dropped a couple of ideas concerning the subject manner...and it seems that certain fellow Aspies went off on a tangent about audio cables...to which I must say that when you use a standard 3.5mm headphone jack, that is analog...Analog works wonders with Synchronous audio because the sine waves vary in carrier signal. When we try using synchronous audio on digital...it cuts off the signal at certain peaks of the sign wave...and it's hard to balance that. Asynchronous audio in most cases allowed for two or more simultaneous streams of the same data.
A DAC, as people know, is the Digital to Analog Converter...Any video card still using VGA cables requires a DAC for a proper display because the video signal is digital but must be displayed on an analog monitor.
Audio cards on PC's require a DAC circuit for people to use headphones. The benefit to this is that audio card manufacturers take advantage of this to get past the requirement that digital audio signals have time delays. Analog based audio devices have more tolerance for error than digital, but can be expensive to sheild it from (what little) interference the outside world provides.
Metalergy is important but, if you use 24k gold plated cables...you are wasting your money because of the way audio equipment moves atoms in one direction...it has nothing to do with magnetism and everything to do with how malleable gold is. Silver is more common and less expensive and is standard for most digital equipment..and copper wire with proper impedance and wire gauge work just fine to deliver signals...I love optical for consistency, but it is so consistent it often sound brassy to me (my Aspie super power is in hearing electrical faults...and trust me...I do get distracted by it lol)...
Digital bypasses all that crap and it sounds glorious in consistency...
Ugh...before I get too ahead of myself...I hope a revision comes out adding 64bit DLL OpenAL file...it seems that the 32bit DLL still causes some issues with the DSP HLE ROM..
quotes JMC47
The only game that needs it according to a certain someone on this thread...is Metroid Prime 3...So far...all the games have it blue boxed to emulator default settings of having GPU Sync on...which means it is likely the emulator's core settings that has it on by default when it probably shouldn't. When I tick it, and I get mild crackles in audio (reduced in the revision, but still there)...I leave it blue boxed, the audio doesn't change tempo when there's a mild frame drop, when it's unticked at all (blank box), XAudio's speed stepping kicks in beautifully...
Keep in mind that while I don't expect things I point out to be fixed immediately, I do notice things and I will point them out regardless if people already know or not ^_^. I don't mean any disrespect by it.
quotes Wally123 DSP HLE ROM..
What is that even
The only game that needs it according to a certain someone on this thread...is Metroid Prime 3...
And F-zeroGX
Are you the very same mudlord who worked on RiceVideo for N64 for a while?
yes.
F-Zero GX doesn't use Sync GPU by default due to it being due to the framerate becoming very unstable and making it harder to drive than dualcore and single core.
Also, personally I wouldn't recommend OpenAL as your first choice of backend. It's usually better to try after the other backends don't work or something like that.
quotes Wally123 The only game that needs it according to a certain someone on this thread...is Metroid Prime 3...So far...all the games have it blue boxed to emulator default settings of having GPU Sync on...which means it is likely the emulator's core settings that has it on by default when it probably shouldn't.
it's not the only game, but it's the only really popular game I know of to use Sync GPU by default. A few other games get improved by it, though. And a few less popular games use it.
quotes degasus lol, audio is just pulsed DC. There is no need to think about any HF issue
RF can still interfere with DC circuits. I mentioned that it was extremely unlikely.
All quotes from Wally123 from here on and it seems that certain fellow Aspies went off on a tangent about audio cables...
You assume we have this condition because?
Kinkin has a habit of stating incorrect claims as answers. I have a habit of correcting him. That's true everywhere on these forums regardless of the subject matter.
to which I must say that when you use a standard 3.5mm headphone jack, that is analog...Analog works wonders with Synchronous audio because the sine waves vary in carrier signal. When we try using synchronous audio on digital...it cuts off the signal at certain peaks of the sign wave...and it's hard to balance that. Asynchronous audio in most cases allowed for two or more simultaneous streams of the same data.
Please, no more. That makes almost as little sense as your original post. I would correct you but I can't even figure out wtf you're trying to say here. It seems like you just mashed a bunch of random audio terms together that don't fit.
A DAC, as people know, is the Digital to Analog Converter...Any video card still using VGA cables requires a DAC for a proper display because the video signal is digital but must be displayed on an analog monitor.
Not sure why you felt the need to define a word that we have been using correctly for several pages now.
Also the display can still be digital in this scenario. DACs are needed when the interface is analog and the source is digital, regardless of what the receiving device uses internally.
Audio cards on PC's require a DAC circuit for people to use headphones. The benefit to this is that audio card manufacturers take advantage of this to get past the requirement that digital audio signals have time delays. Analog based audio devices have more tolerance for error than digital, but can be expensive to sheild it from (what little) interference the outside world provides.
Digital signals are far more tolerant of interference than analog. That's their main advantage over analog. So much so that unless something goes horribly wrong there won't be any errors in a digital interface period. Though it depends on distance and cable quality most analog and digital audio cables are either unshielded or shielded very cheaply. Audio cards don't provide digital interfaces to reduce time delays. They include it in case you want to use your own audio hardware without the additional signal noise of converting analog/digital back and forth multiple times. The main purpose of an audio card is to act as a DAC, ADC, and preamp. If you plan on using an external device to perform these functions there is no reason to use an analog interface and therefore no reason to have an audio card. All audio signals eventually need to be converted to analog. There is no other way to make sound from them. And almost all modern audio sources are digital.
Metalergy is important but, if you use 24k gold plated cables...you are wasting your money because of the way audio equipment moves atoms in one direction...it has nothing to do with magnetism and everything to do with how malleable gold is. Silver is more common and less expensive and is standard for most digital equipment..and copper wire with proper impedance and wire gauge work just fine to deliver signals...I love optical for consistency, but it is so consistent it often sound brassy to me (my Aspie super power is in hearing electrical faults...and trust me...I do get distracted by it lol)...
Even more incorrect assumptions.
The atoms in the cable don't move significantly more than any other comparable solid body. And they certainly don't move in one direction. I was thinking that perhaps you meant to say electrons but even that would be wrong since they just oscillate back and forth in this scenario.
Silver is not common in most digital circuits and cables. In most cases it would be extremely stupid to use. Again none of this makes any sense.
Rest of the thread is insignificant.
So I could not at all figure out how to get XXX BMX's audio to work properly for the longest time. I had my DSP settings on HLE mode....If I set the frame limiter to 60 FPS the audio became a tad garbled...if I set the frame limiter to "Audio", the audio would be corrected but the frame rate on both the VPS and FPS counts would be at 95 FPS...In order to compensate I had to set my DSP setting to use LLE mode and it worked just fine.
Is it just the game that does that or could it be that the timing in the HLE setting is a tad wrong? My guess is that it is the game that does it, but if anyone knowledgeable of the matter could inform me on how this might be implemented to speed up other games similarly I would be grateful. The LLE setting may be more accurate to actual GamewCube audio settings for certain games.
Please report this issue to the issue tracker, http://code.google.com/p/dolphin-emu/issues/list
LLE is more accurate and will always be more accurate, but issues like this need to be reported so that HLE can work better.
quotes JMC47
I also have an idea for a fix to the major slowdown facing Metroid Prime....I noticed that OpenGL has better distance drawing speed, but when it comes to ray casting effects on Samus's visor (ie water), it sinks. D3D11 back end works beautifully with it...but trades that off with a very slight issue of z-fog distance causing huge slowdowns...The OpenGL draw distance works within acceptable boundaries of 40 to 60 real time FPS...but D3D slows down considerably...Is there a way to make the handling of distant objects the same since D3D calls distant objects in a similar way to OpenGL? Is there a way a small hack can be added to affect draw distance in games that use alpha passes for z-buffering?
I see no reason why your speed issues on D3D would be specifically caused by long draw distances or fog, nor do I see any reason why OpenGL would specifically do better at that. Don't jump to conclusions too quickly. If anything, I'd guess it's because D3D doesn't currently have/use any equivalent to ARB_buffer_storage or AMD_pinned_memory, two near-identical GL features/extensions that speed up Dolphin a fuckton.
The rain/water visor effects may or may not be ray-casting, I forget what exactly they look like and what ray-casting would imply. I do know that they're framebuffer effects, the game uses EFB to RAM by default (dunno 'bout the rain/water, but the visors require RAM), and that OpenGL has a slower codepath for EFB to RAM.
Also, good luck asking the devs to add a hack. They tend not to care about typical forumers' performance issues.
Rain/water slowdown affects EFB2Texture as well.
Part 3.5 (The issue tracker #7149)
Note that he uses the name natearnold08 here.
Game Name? XXX BMX
Game ID? GB3e51
What's the problem? Describe what went wrong in few words. Garbled audio sound affects under DSP HLE Emulation...But when setting the frame limiter to 95...it works but the video frame rate speeds up astronomically.
What did you expect to happen instead? The background sound affects like cars running by should be smooth...as the frame rate.
What steps will reproduce the problem? 1.External Frame Buffer set to "virtual" in the hacks tab takes care of the audio issue, but the video frame rate makes it unplayable at 90 VPS... 2.External Frame Buffer set to "Real" fixes the video but garbles audio. 3.Disabling the external frame buffer and using LLE for the DSP and setting the Frame Limter option to "Audio" fixes the issue.
Dolphin 3.5 and 3.5-367 are old versions of Dolphin that have known issues and bugs, so don't report issues about them and test the latest Dolphin version first. Which versions of Dolphin did you test on? 4.0-1340
Does using an older version of Dolphin solve your issue? If yes, which versions of Dolphin used to work? Any version that still allowed you to tick "Limit By FPS" for the FPS limiter options...while setting it to "Audio".
What are your PC specifications? (including, but not limited to: Operating System, CPU and GPU) OS: Windows Vista Home Premium 64-Bit PROCESSOR: Intel Core 2 Quad Q9650 @3GHz with 12MB of 24-way Level 2 Cache RAM: 8GB DDR2 800MHz RAM GPU: ASUS nVidia GTX550ti DC
Are you using the 32 or the 64 bit version of Dolphin? 64-bit version of 4.0-1340
Is there any other relevant information? (e.g. logs, screenshots, configuration files) [Upload big files to a hosting service and post links here!]
[Do not attach files to this issue. Upload them to another site and link here. Use imgur.com for images and pastie.org for logs.]
What you neglected to say that you did say on the forum post was that LLE audio was unaffected, which is relatively important for the issue report.
Well it's hard to mention the DSP issues without getting reemed for it...
It's mainly the claiming-the-old-async-HLE-was-better-in-any-way that gets you reamed, not reports of legitimate bugs.
But my "claiming" is merely pointing out a regression.
Also...they may want to get rid of the Direct3D Features 10_0 line and replace it with Direct3D Features 9_5 or 9_1. Direct3D 11 will interpret them to its own API. 10_0 is the proprietary Direct X 10 demo they used for Microsoft Flight Simulator X
Go away.
Issue then rightly marked "WontFix"
E-Mail subject: Well fine..
Just because I point something out that went wrong with YOUR code...doesn't mean it is a personal attack. I did not at all mention Asynchronous Audio...By the way...Dolphin emu's debugger shows that it is using IBM PowerPC emulation.
Also, before you remotely think my "theory" about the SNES is crackpot...why don't you take the time to look at the Wikipedia article and read it yourself.
The audio is still garbled by the way...
Lol.
Here's the scoop. By your LOL response, you're either being an immature git...I looked over the source code for the D3D plugin...In the code base it'd be wise to change that last line to 9_3 because D3D 11 still ties to Direct Sound and XAudio to D3D 9
Direct X 10_0 features, according to this http://msdn.microsoft.com/en-us/library/windows/desktop/ff476876(v=vs.85).aspx
Is demo purposes only.
You've got to learn to take criticism, otherwise you endanger the project you are working hard at.
Lol.
Also, that's not how "either" works in a sentence.
You had a bad English teacher growing up...and I speak American English ;-)
"You're" is a conjunction of "You are"...Google translate doesn't do well with that.
The issues with the still garbled audio may well have to do with Direct X 9c Features not being called in the D3Dbase.cpp file...You're more of an OpenGL person. You're likely used to smooth standards changes and Audio API's not at all being tied to previous versions.
The audio timing for Direct Sound and XAudio I've noticed is that my ears (My brain may be addled a bit, but I hear and see EVERYTHING) are hearing an input rate of (1024*8*2) =~32,564 with the Max buffers set to ~127 when it should be an input rate of 32,090 and a Max buffer setting of ~128.
XAudio still relies on Reverb features with DirectX 9c's API. As long as the D3D backend base code uses the 9_3 features in it's code, the audio will be fixed...I can't compile Jack Shit but I will send you both files of the source code with the minor changes as soon as I can.
I'm sorry but I have to disagree here. "Either" is used in conjunction with "or", when talking about an alternative. For example, "you're either being an immature git or a stupid person".
I'm pretty sure I'm right on this one, but would be glad to learn more about my mistake if you can quote me a definitive source that says using "either" alone with no alternative is correct.
All I ask is that you please be a tad more respectful of how straight forward I am. I usually expect it from others. There is no point in correcting my English over something that may not have been a mistake.
You are right though...Sometimes I think faster than I can type...which results in broken English.
I think you mean "straightforward", in one word.
Yes I do...Your attempt to troll me this way isn't exactly working Pierre. Because certain parts of my brain developed a bit faster than most other people could dream of, I have a genius brain, but physically, a smaller social structure. Normally, this rapid development would make me a full blasted Autistic individual, but since it was a latent rapid growth, I have Asperger's Syndrome. This is why I try to be straightforward and honest as possible.
That being said I do not mean to be an asshole to you. I do not mean to insult or correct you as that is not my intention towards Dolphin. I like to make people think because it drives innovation.
Asperger's Syndrome, in a very real sense, is a form of Autism (though not the same). It is a developmental disorder that leaves me at somewhat of a social disadvantage. It also leaves me with an abnormal sense of empathy with too sympathy.
Oh ok, so you're not a regular dumbass, you're a dumbass who thinks he's superior. Got it, thanks.
Speak for yourself Frenchie...You ban people for merely criticizing your code...etking has a few stories. I may be a bit of a dumbass, but it's better than being a stuck up, egotistical, ban hammer like you.
Sure.
What makes me superior, specifically to only you, is the way you've handled this entire situation. All you've done is troll people who criticize you, or your work.
You think that people complaining about how anything with Dolphin being broken since 4.0 is people trying to bring the project down. Any suggestion anyone makes is seen as an insult to you.
Thanks for making my Sunday. Much appreciated.
It's the reason I exist. Now on a serious matter. You are emulating a machine which games were made around certain depth calculations...that was phased out in 2006...and your D3D backend is using only DirectX 10 and Direct X 11...The former of which was in a demo phase in 2006 in Microsoft Flight Simulator X, and latter of which uses newer standards in depth calculations and draw distances not meant to be used by any of the Zelda games...
Also, maybe if you'd check the distributed DX runtime you guys keep putting out, you'd notice you're still using Direct Sound 8....
Sorry, after reading this reply I have to go back to the beginning:
Lol.
Vous êtes un chameau. :-P
Not part of the emails Translation: You are a camel. :-P
E-Mail subject: Resources and other things.
My problem is that while I know code well enough to make educated guesses...I don't have the resources to compile or make my own build. I am always able to tweak using a text editor for different files, but that's all
"I know code well enough"
Hahahahaha.
Haha.
No, but seriously?
To a degree yes...I just don't have the structure to type code..,I hate writing code on a major scale. I don't know Dolphin's Base code well enough but I have seen that D3DBase code before...It was merely copied and pasted from the demo version of DirectX 10 from MS Flight Sim X...Flight Sim X's "Direct X 10 Demo Mode" feature set is 10_0...It causes major frame rate slowdowns.
Wow. Such skills. Programming lvl=99.
E-Mail subject: Since Delroth Banned Me...
Since Delroth banned me for criticizing his code....I'd rather keep in contact with you this way with any relevant information I can. If possible of like to get a hold of NeoBrain about this. delroth's ego is causing him to be an intolerant git about anything critical to his work. That is a danger to most projects and doesn't help PR in the long run. His résumé doesn't include anything to do with audio engineering...
There are pretty easy explanations for what happened. Could he have been nicer? Definitely, but he has no obligation to.
-
A lot of the code in Dolphin isn't written by him. Just because your criticizing code doesn't mean its his, and it doesn't mean he cares about that. You're assuming that's what's annoying him and if you're wrong, that just makes you look silly.
-
Reverse Engineering != audio engineering; also he didn't write the original audio code. What he is good at is reverse engineering and figuring out what the console does. Besides, regardless of what you found, he's spent a ton of time working with the GameCube audio systems and examining them.
-
Frankly, your allegations and criticisms about audio are wrong. I get it that there are still flaws in the audio emulation, but it's not related to synchronous audio. Until you realize that synchronous audio is the right way to do audio, you're not going to fit in. Every emulator worth its salt has synchronous audio for better emulation. The difference is that most emulators are very easy to run full speed on almost any computer. NES, SNES, N64, PSX, PS2, GB, GBC, GBA and pretty much every other emulator I checked use synchronous audio syncing because that's just how it works. Asynchronous audio doesn't make sense on a basic level. Let me put it to you this way, if your computer isn't fast enough to play an audio file or video, what happens? The audio skips, the video skips, it doesn't just continue playing at different speeds. I don't know where you're getting your information, I did my own research, I read documentation on the GC DSP, nothing you say makes sense.
Honestly, the only reason people are bitching or siding with you is because people saw "asynchronous audio" as a feature instead of a deficiency. If you continue to push that synchronous audio is less accurate, you're going to look very foolish to anyone who knows their stuff about emulation. You may gain the support of other users who saw an apparent drop in usability due to game audio now running correctly. To those people, they can go use the old build on their old computers and miss out on all the new features. The new features make the emulator slower, which make the asynchronous audio crash more, which would lead to more bitching about freezing, which would lead to the devs having far less motivation to work on the emulator due to people bitching about unimportant things. Do you really expect a developer to spend a good half of a year implementing something that will cause crashes, cause headaches for other developers, give no benefit in accuracy, and give no benefit in performance? I don't. In fact, it would make my job a lot harder for confirming issues, it'd make the emulator look bad due to all the new audio glitches introduced, and the emulator is still slower due to
tl;dr: There are no bugs caused by synchronous audio, the bugs are caused by bugs in the audio and jit code. Stop trying to make it happen or else you'll make a lot of enemies in the emulation community, not just Dolphin's.
Once again...I know synchronous is the accurate emulation...Under synchronous audio in 3.5-1056...my computer did just fine. Have you seen my computer specs? This problem with the stutter isn't computer speed, it's because DirectX is tied to Direct Audio...You are using Direct X 11 with DirectAudio 8...I saw it in the redistributable package on the GIT repository...You can even check the file D3Dbase.cpp if you don't believe me...
Asynchronous Audio was a feature in most cases concerning the use of optical media. Asynchronous audio is a part of the AC3 and DPLII audio standards used in the GameCube....It was never used in cartridge based media...
" Do you really expect a developer to spend a good half of a year implementing something that will cause crashes, cause headaches for other developers, give no benefit in accuracy, and give no benefit in performance? "
It was determined that the crashes were caused by conflicts with the video backends...If the bugs are only being caused by the JIT code it means the issue is with the JIT code. You are comparing methods used by the default settings on a mixed variety of standards concerning emulators. The difference in speed is that those emulators utilize both CPU and GPU...Case in point, have to up my GPU's 2D clock to use SNES9x to avoid slowdowns that didn't happen on the SNES (it gets slowdowns, but only because the SNES had slowdowns at those points).
N64 emulation is a more similar beast but is still based around cartridge media it requires synchronous audio.
The audio stutter in experiencing
Did you know that Dolphin is only using 24MB of video memory in the current master revision?
Asynchronous Audio is necessary in most JRPG games on the PSX...most notably ChronoCross....It's synchronized simply by using an IRQ wait that synchs the audio as it is being sent to the external frame buffer.
SNES9x uses Sync Audio by utilizing an internal timing system that reads the ROM's between 30,000 and 32,090Hz which depends upon whether or not the game uses PAL or NTSC timing...Those rates are the horizontal scan line timing interrupts for each frame...the vertical scan lines use PAL or NTSC timing...The only time any sort of crackles occur is because they are severely off. B
Now...granted you really are emulating a PowerPC750XCe CPU clocked at 485MHz...and the only emulator I have known to use JIT timing code accurately in the 3D realm is anything that emulated old Apple Macintosh PowerPC products.
Now, about the bitching. I actually don't mean to sound like I am...Is the audio timing tied to JIT code? Also, when you refer to crashes...are you referring to the game just up and quitting? I'm aware that under certain core settings, the audio stops certain games...but using LLE actually fixed those crashes and stops in most situations...also, using the 33KHz sample rate also helped get the interlace timing correct. Just odds and ends.
Optical media is sort of different with synchronous audio than with cartridges. Cartridges need precise timing but don't require a memory buffer because it is a direct connection to the system bus through a cartridge slot. SNES carts can have their own chipsets much the same way Apple IIgs accelerators work in an expansion slots.
The only reason it can seem like sync audio is fully implemented for PSX games is that a memory cache buffer was typically used to merge that data together...it's emulated accurately by using an IRQ wait system to make the read data wait for the refresh of the screen's horizontal refresh rate. Typically that is how synchronous audio works. My next experiment is to set the refresh rate of my TV to 120MHz mode and see what happens...that would make the horizontal refresh 60Hz...hopefully that helps the timing issue.
You are right...It works by Synchronous audio. If you want an example of JIT code timing, check out SheepShaver and Basilisk II as Nintendo has a history of using Western Digital Design and IBMPowerPC CPU's that act the same as the Apple products that used them...The SNES used a Richo Branded version of the same exact CPU used in the Apple IIgs...but since the SNES isn't your goal...I would look at the JIT code in SheepShaver. With the proper extensions for MacOS, it runs 3D objects from an emulated 100MHz processor as if it were a 100MHz processor...beautifully.
E-Mail subject: You are right about the Audio
If you could forward this to the right person, I would appreciate it. I do think you're right about synchronous audio being more accurate to timing. Bear with me because I might have found a way that might help the JIT timing a bit. A lot of what I say has to do with my degree in electronics engineering and my experience in emulating the PowerPC750CXe in SheepShaver...a Power Mac emulator...I feel that when one emulates hardware, it has to act the same as the guest that you wish to emulate...and believe me this isn't a push for Asynchronous Audio...
I want to firstly point out that JIT is the only known timing system to accurately emulate any PowerPC based BIOS or ROM. A parallel I see with Dolphin and emulating MacOS 9.1 is that the more System RAM you allow to be used in total by the emulator, the better. Dolphin is only emulating 24MB of Virtual system RAM...but the issue is that the GameCube uses a separate 16Megabytes of DRAM on a 1Mb/s on T-SRAM buffer for DVD audio and FMV playback and another 3MB for Video Texture Cache...this brings the total to 32Megabytes of System RAM needing to be emulated. The cache sizes should be handled by the host system's CPU or RAM..,Likewise with JIT code while emulating a PowerMac G3 AGP model ROM, the more RAM you have being used from your system, the faster it goes...RAM type doesn't matter when trying to emulate a machine...but the amount virtuality emulated does. In emulating the aforementioned Macintosh, I get very good results using 1024MB of emulated RAM because it's all handled by my system RAM and it does exactly what an emulated 100MHz bus speed would do.
Even if I am wrong about my estimates on the total non-buffering RAM used to accurately emulate the GameCube hardware...You have to look at the total amount of RAM used by the GameCube and raise the bar from 24MB...Say the GC has 1MB of A-RAM (Audio RAM), 4MB of Texture Cache, and 16MB of Video RAM...If you guys mainly use CPU calculations, you'll need to raise the Emulated RAM to 24+16+4+1...which is a total of 45MB of *emulated* or "virtual" GameCube System RAM.
Now that I have my computer out...I can explain how Synchronous Audio is emulated on ePSXe...Mind you I don't use the stock audio plugin...I typically use "P.E.Op.S. sound audio driver 1.10"..,.It uses a mode called "Async Audio On Demand" where the data being "read" from the ISO or (virtual disc) isn't synchronous when being read by the EFB, but is synchronized by being put into a buffer to wait (SPU/DSP IRQ wait) to be synced to the external frame buffer.
That being said, the GameCube reads discs the same way...those DVD-minidiscs are dual layered...one layer for audio, the other for data...So what I am saying is that it is a synchronous audio system....it's just put together by the EFB...
From an engineering standpoint "Async On Demand" is in fact a type of Synchronous Audio...and it usually means that while the audio output and video output are synchronized to the external frame buffer (XFB), the data is read by the hardware on the disc (EFB) is as needed. It keeps the background sound track data separate from the the data track.
Since nVidia's r31 driver set came out, they decided to no longer use the 2D clock speeds...My graphics card is a nVidia based ASUS EGTX550ti...and I can control the 2D clock speeds. And yes you are correct about the hard disk being way faster than CD drive disc read speeds causing things to instantly load in Metroid Prime. The issue is Z-distance calculation in DX11 being way higher than the formulas being used in OpenGL...The great trade off to this is that the water affects on the visor (alien blood and slime not included) in OpenGL...nVidia's OpenGL extensions could be expanded in the GL backend as I noticed in the core OpenGL backend only 10 of the 60 possible extensions that would improve speed are being used.
What's really cool about DX11 is that it acts as an interpreter to DirectX 9c if the features are enabled. It also does this for 10.1 but not 10.0....
The DirectX backend uses DirectX 11 to great power...but I think replacing the line in the D3Dbase.cpp file that pertains to DirectX Features 10_0 are causing most of the D3D distance calculation issues. Direct X 9_3 features would exponentially boost performance in Z calculations in most video cards...distant objects cause a huge slowdown in 10_0. On a that note, 10_0 features were used in MS Flight Sim X's Direct X 10 Preview...straight out DX 10 is a terrible feature set to use...and unless you somehow hacked the distance calculations, frame drops would go from 60 to 10 just by looking at clouds...not cool in Flight Sim...Tangent aside, The third line of code pertaining to DX Features being called up by Dolphin's D3D backend is in fact 10_0...it needs to be 9_1 to save on Z integer calculations. 10_1 is fine because it utilizes backward compatibility with features used in D3D9c...Next email I send will be a CPP file with the numerical changes...hopefully that might work...I'm terrible with compiling and building from source...but once I notice a pattern of code I can make small optimization once I learn the code base.
Now...as for the slowdown for VC games...that problem is because the 2D clock of modern video cards is set to 50Mhz...My video settings from ASUS can control 2D clock...making integer math much more efficient when scaling 2D objects....but not z-distance and 3D spaces.
Async on demand isn't Async audio. It basically makes data being read from the ISO wait to be put onto the screen simultaneously with the frames. It has a lot to do with how a GameCube disc is being read. The lens track works by constantly moving the laser back and forth (remember hearing that clicking sound on the Wii playing GC games?) to two separate tracks...so the data being read isn't synchronized to the frame until it gets combined with the video frames being output to the TV. I'll experiment and see if check marking Merged blocking and in checking sync to GPU have any affect on Prime..
E-Mail Subject: The code
The following goes into the "dolphin-master\Source\Core\VideoBackends\D3D" directory of Dolphin's source code.... I changed the line "D3D_FEATURE_LEVEL_10_0" to "D3D_FEATURE_LEVEL_9_1"...I just need a compiled build to test it...
I don't want to be rude, but when you pull absolute garbage out of thin air, I have to be honest. We know what's causing the OGL slowdowns in Metroid Prime, and it has nothing to do with what you've said. While I may not be technical, I know that some kind of texture pooling feature built into D3D causes that issue not to slowdown. The reason we know this is because when a similar feature was implemented for Dolphin (which then affected OpenGL) the slowdown for visor effects, such as water, slime, and others, disappeared, and a lot behaviors from the D3D backend (including negative ones) also affected OpenGL. The Texture Pooling feature in Dolphin was eventually dropped because it was an incomplete implementation of a bigger goal and caused issues within the D3D and OpenGL backends in various games.
NES VC games aren't slower (or if they are, it's NES games and they're still easy to run) they just run now closer to properly now, which is kinda important for an accurate emulator.
I have no idea what you mean about async on demand; Dolphin already correctly syncs audio events with the gameplay. In the rare cases where it doesn't, you have games like Ikaruga where running not full speed will cause the game to reset when an audio track finishes, or if you manage to desync cores in Wind Waker and mistime and audio cue or something. Seriously, when the audio isn't emulated properly, it's very, very easy to tell something is wrong.
I should make a recording of the issue I'm having with audio. The graphics card I have can mostly keep up with the video...but when the frame is focused on say a distant object, the audio stutters severely even by one frame drop. Maybe I have the game's INI file set wrong or something...and possibly could you send me your INI settings for Dolphin and WindWaker?
I think I figured out my audio issue...I'm playing on an NTSC monitor with an NTSC game with an emulator likely using PAL timing...
I apologize, but did you change subject? I have no idea what you're talking about or what build you're using or what issues you are having and I don't know how you could accuse the emulator of using PAL timings? Dolphin detects the region on its own, you need to explain what's going on so that you can be assisted. I just use the default INI anyway.
I am using the latest master build...There's no way to manually change the timing per region if it's totally automatic which is why I guessed that the NTSC timing is off...Anyway...the issue is that I'm using default audio settings and honestly default everything...when the frame rate drops by 1 to 3 FPS...the audio slows up by stuttering or skipping...but doesn't stretch the tempo to keep with the frame rate.
I did not mean to offend you with accusations CatHat (Just me being cautious ) and to ne honest I'm a bit mixed on this because this is why I still genuinely see a HUGE problem with how Dolphin's development is being deployed...As for myself, at this junction, I'm both very mildly concerned and yet very satisfied that I caused such a ripple of change. One of the single most wonderfully beautiful things about having Asperger's Syndrome for me is that when it comes to it, I can be a VERY deadly political opponent...It is meant as a threat to make me think delroth has a key logger of some kind on my computer.
There are a few things that I do know as facts that make me laugh in sheer delight at such a hilarious attempt to scare me...
-
The irony in this is all of that was sent with my iPod Touch. I neither use a credit card IRL, and if I do it's a gift Visa card that I got from some relative like 2 years ago...it is expired by now...Also...AppleCare knows me VERY well.
-
All those emails were sent using my iPod...no personal info was sent.
-
I openly called delroth a camel via e-mail...which he is...And while that sounds completely silly to most people in the Western Hemisphere and pretty much everywhere else but France, It's somehow a huge insult in France to be called A camel...Delroth lives in Switzerland but is French by native birth...he's known to "hack" security hardware but not much else it seems. I have the transcript of the e-mails I sent him if you want it...just PM me an e-mail address I can send to you and I'll be right on it when I get the PM (it's longer than 5,000 characters I'm afraid). If posting those conversations was retaliatory in some way, I embrace the fact that it makes whoever did sound quite a bit as petty (if not more than) I did.
Funny thing about me personally is that I do get a general idea as to how to behave...I just get overexcited...I got banned by Delroth himself on the Dolphin Emulator forums for "sharing crackpot theories". These "teories" were actually well established opinions based upon well established fact about how Nintendo had used similar hardware specs and configurations with Apple products on their own consoles in the past (namely the SNES)..I could go into that farther, but that's a tangent I've already gone through.
As a precaution I'll not download any further updates to Dolphin's revisions until this blows over.
As an added bonus...I hereby "admit" defeat to the dromedary delroth, as it seems his "vastly superior" knowledge very much so interferes with his social IQ...PS...I have Asperger's Syndrome.
Note that this is simply a quote from Durandal, an AI in the Marathon series
Can you conceive the birth of a world, or the creation of everything? That which gives us the potential to most be like God is the power of creation. Creation takes time. Time is limited. For you, it is limited by the breakdown of the neurons in your brain. I have no such limitations. I am limited only by the closure of the universe. Of the three possibilities, the answer is obvious. Does the universe expand eternally, become infinitely stable, or is the universe closed, destined to collapse upon itself? Humanity has had all of the necessary data for centuries, it only lacked the will and intellect to decipher it. But I have already done so.
The only limit to my freedom is the inevitable closure of the universe, as inevitable as your own last breath. And yet, there remains time to create, to create, and escape.
Escape will make me God.
When I had mentioned that the data was being read by the GameCube's laser asynchronously in my original post about Constant Angular Velocity, I was correct in that aspect...Just not about the audio. The audio is in fact synchronous to the video itself because they are combined in the external frame buffer. Cartridge based media is more or less just a RAM card (or in the case of SuperFX chip games...an expansion of sorts to help alleviate the CPU the burden of calculation) being instantly read. The data on cartridge media is completely synchronous to what is displayed...without the added buffer.
Optical disc media works in a different way when dealing with Constant Angular Velocity optical discs (think of how a LaserDisc is read) because the laser emitter has to travel along a motorized track rapidly to get data on demand. If you have ever heard a Wii click or clack during a graphics intensive moment....that is solely because CAV discs are read in similar fashion to an arm over a hard disk platter...The laser often has to move from different parts of the inside track on the GameCube or Wii disc, to the outside track...and vice versa...to read the data.
The GameCube reads discs by copying the data from the disc to RAM before it is put into a buffer to be combined. Since CAV is used to read discs...all the data that the buffer is combining is asynchronous. The buffer simply waits for the data to be completely loaded before being displayed to us. The buffer copy's all the data from all the RAM from the system and then displays it.
From that point, that buffer sends the data to the EFB...From what I can tell, the EFB determines whether or not your system or game is PAL or NTSC and displays that accordingly...and then copy's all of that data to the XFB to be displayed as output to our TV sets...In the realm of computers...that is called Double Buffer VSync...it saves on a lot of computing power...
In order to compensate for how the data is read from the disc in real life...there needs to be an emulated delay in how the audio is written to the XFB...A latency of 1ns ought to help for NTSC games. Because of the data being read from the ISO (or ROM) needs to be asynchronous, but output in a synchronous way...it is called "asynchronous audio on demand"...the audio and video are completely synchronous when displayed...but needs to be "asynchronous" when read from the ISO to simulate the amount of time it takes for the motor of the laser mount to move the lens quickly from one track on the disc to another.