Why asynchronous audio should not have been removed....and an idea.

[delroth]

(03-30-2014, 08:03 AM)Wally123 Wrote: 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.

[JMC47]

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.

[Xtreme2damax]

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.

[Wally123]

(03-30-2014, 08:10 AM)delroth Wrote:

(03-30-2014, 08:03 AM)Wally123 Wrote: 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 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.

[JMC47]

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.

[degasus]

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?)

[Wally123]

(03-30-2014, 10:25 AM)degasus Wrote: 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?)

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...

[shuffle2]

Have you tried using Monster cables?

[kinkinkijkin]

(03-30-2014, 11:42 AM)shuffle2 Wrote: Have you tried using Monster cables?

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

[Sonicadvance1]

(03-30-2014, 11:51 AM)kinkinkijkin Wrote:

(03-30-2014, 11:42 AM)shuffle2 Wrote: Have you tried using Monster cables?

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

Sarcasm is hard to catch on the internet. Should have used a master ball.