Possibility of implementing ASIO driver for low latency and bitperfect audio output

RetroArch Windows devices
#1

First and foremost, I apologize if the inquiry I’m posting here might sound completely inaccurate, unfeasible or straight out of science fiction. I’m not a programmer by any means, simply an enthusiast who occasionally wonders about how things work.

I was dabbling around in the configurations of Retroarch and noticed that the Windows version currently provides the user with three different options for the Audio driver: directsound, xaudio and sdl2 (in addition to ‘nulling’ the audio entirely). Each one of these possibilities yields different results and, based on my experimentations, varying extents of tolerance with the Audio latency setting. Xaudio works fairly well for most cores and allows to bring the overall latency down by quite a considerable amount if compared to the default value of 64ms.

That being said, I’m curious whether an implementation of ASIO driver can be coded in Retroarch. It’s a popular solution that is commonly employed in both audio playback and audio production and it’s lauded for two significant benefits:

  • bitperfect output, with the target application taking exclusive control of the audio and muting anything else (similarly to WASAPI);
  • extremely low latency.

Once again, it’s an aspect I’m questioning without any in-depth technical competency on my part, but I was wondering whether this could actually be implemented one way or another. Thank you in advance for any insight!

RetroArch + ASIO
#2

There are licensing issues with linking against ASIO, which people handle in various ways. We already have working JACK support in linux, and I suspect that hooking it up for Windows is probably the path-of-least resistance for us. JACK on Windows currently only supports 32-bit but they’re apparently working on 64-bit. Once that support arrives, it shouldn’t be terribly difficult to extend that backend to Windows builds.

#3

That definitely sounds promising. Does the same limitation apply to WASAPI though? I’m curious whether that could be another option for users of the Windows builds, as I guess it could likewise grant some tangible benefits with audio latency.

#4

I believe WASAPI would be an option, yeah, it’s just a matter of someone writing the driver for it.

#5

It appears that, as of v1.9.8, JACK2 for Windows comes in a 64-bit flavor. An exclusive-mode audio solution for an emulator sounds like a dream to me… or maybe more like a flashback as I grew up on DOS emulators. :stuck_out_tongue:

#6

Has anyone taken a look at JACK2 support for Retroarch on Windows?

#7

A little bit. I think it should be usable on Windows already if we just had the correct libs on the buildbot. The problem is msys2 doesn’t have JACK libs, so we can’t test it.

#8

Does that just mean it would have to be built manually for the time being?

#9

Yes, if anyone is up to building all of the dependencies (and their dependencies’ dependencies…) and then building retroarch to see if it works, I’d be very curious to see it.

#10

@hunterk, I was looking at an old post on your blog and I saw a reference to an experimental WASAPI external audio driver written by @Maister, do you have any idea what happened to that? I can’t find it anywhere on Github. I’m aware external drivers haven’t been supported in RetroArch for a long time but it might be worth merging it in as a starting point for a more complete implementation.

#11

We dug all through the git archives and it seems maister never actually committed it anywhere, unfortunately :frowning:

It was apparently deemed not worth the trouble vs xaudio2, since I think it was using shared mode and exclusive mode was super-crashy.

#12

For a while I had to use a 96 ms buffer to avoid crackle… Some cores could still require it for my setup. Now that I’m able to use 64 ms, audio is on par (or lower than) video latency. I’m still jealous that Linux has a cleaner solution. That and I hate XAudio2 for setting back sound in native PC titles a good 10 or 15 years. Yeah, I know, libretro wouldn’t benefit from any of the ripped out DirectSound3D features, but the association is a source of bitterness still. (And don’t even get me started on Aureal3D :P)

Edit: Arg, I accidentally edited this post, destroying the original, instead of replying to hunterk’s next message. I guess it doesn’t really matter.

#13

Lower latency is always good but there’s not a lot of point in pushing it below video latency, which it already is with xaudio2. You can make an argument for it with rhythm games but even that requires playing it “blind” (i.e., basing all inputs on audio cues rather than visual ones).

#14

A WASAPI audio driver was created after a bounty was posted for it: https://github.com/libretro/RetroArch/blob/master/audio/drivers/wasapi.c

However, it doesn’t seems to work with Realtek High Definition Audio chipsets at this time, it freezes when loading content with any core. (See edit below.) There is an ongoing discussion about this driver on Github. More testing from people with different hardware setups would be ideal.

Also, as a side note, I am also unable to get higan v102 working with WASAPI on the same hardware, it never outputs any sound regardless of whether it is set to shared or exclusive mode.

EDIT: I was able to get it working when I re-enabled “Pause when menu activated” in User Interface -> Menu. After doing that, it no longer freezes upon loading content. The other issue is that it will lose audio if you toggle fullscreen while the game is running, but not if toggled while paused in the menu. Other than that, it works perfectly for me in exclusive mode with cores such as Nestopia and bsnes-mercury while audio_latency is set as low as possible.

1 Like
#15

We dug all through the git archives and it seems maister never actually committed it anywhere, unfortunately

Yeah, it appears it was only uploaded to multiupload, and the links he posted are long dead. I found the thread that it was posted in 6 years ago, on byuu’s original board:

https://byuu.qwertymodo.com/board/viewtopic.php@f=3&t=1641&start=75.html

It’s kind of disappointing that it was never mirrored anywhere…