Audio cuts out mid-game (or occasionally starts without audio)

[oskeith]

I've been using (and enjoying) RS-ASIO for almost two months now, but it has recently developed an issue where the audio will cut out mid game (or occasionally start with no audio).

I have tested by playing the guitar for an extended and longer amount of time through a DAW (using ASIO drivers and the same interface of course) with no cutouts.

Looking into the log, there appears to be an empty error message

263.007 [ERROR]    Failed to start ASIO stream
263.007 [ERROR]  ASIO Error: 
263.007 [INFO]    hr: E_FAIL

Device info: Windows 10 22H2 19045.4412 Zoom UAC-232 Driver 1.0.0.13

Log files: RS_ASIO-log audio cutout.txt RS_ASIO-log no audio start.txt

Config file:

RS_ASIO.ini

``` # for "EnableWasapiOutputs" you can use -1 to have a message prompting # to use either WASAPI or ASIO for output every time you boot the game [Config] EnableWasapiOutputs=0 EnableWasapiInputs=0 EnableAsio=1 [Asio] ; available buffer size modes: ; driver - respect buffer size setting set in the driver ; host - use a buffer size as close as possible as that requested by the host application ; custom - use the buffer size specified in CustomBufferSize field BufferSizeMode=driver CustomBufferSize=128 # if your game hangs or crashes on exit, try setting "EnableRefCountHack" to true. # when blank or invalid, the value of "EnableRefCountHack" will be interpreted as # true if RS ASIO detects the usage of Asio4All. # the same applies for all inputs. [Asio.Output] Driver=ZOOM UAC-232 ASIO Driver BaseChannel=0 AltBaseChannel= EnableSoftwareEndpointVolumeControl=1 EnableSoftwareMasterVolumeControl=1 SoftwareMasterVolumePercent=100 EnableRefCountHack= [Asio.Input.0] Driver=ZOOM UAC-232 ASIO Driver Channel=0 EnableSoftwareEndpointVolumeControl=1 EnableSoftwareMasterVolumeControl=1 SoftwareMasterVolumePercent=100 EnableRefCountHack= [Asio.Input.1] Driver= Channel=1 EnableSoftwareEndpointVolumeControl=1 EnableSoftwareMasterVolumeControl=1 SoftwareMasterVolumePercent=100 EnableRefCountHack= [Asio.Input.Mic] Driver= Channel=1 EnableSoftwareEndpointVolumeControl=1 EnableSoftwareMasterVolumeControl=1 SoftwareMasterVolumePercent=100 EnableRefCountHack= ```

LatencyBuffer set to 4

Thanks for this project!

[mdias]

It looks like just before it fails you get this log: AsioSharedHost::AsioCalback_asioMessage - selector: 3 value: 0 | returning: 0

This means that your driver is requesting the application (in this case RS_ASIO) to restart/reload the ASIO driver for some reason. This action is not supported by RS_ASIO as of now, so it just ignores it and then it can't successfuly initialize the driver anymore.

It would be interesting to understand why this would happen. According to some documentation, it can happen on some interfaces when certain interface settings are changed, such as for example some setting in it's control panel.

Are you still able to open a DAW and test the interface when it gets into a state that RS ASIO no longer starts even after you reboot the game? Also, the game appears to be using a buffer size of 256 samples at 48000 hz with your interface and current settings; do you use the same settings when testing with a DAW?

Another note, you have this:

BufferSizeMode=driver
CustomBufferSize=128

But the custom buffer size is only respected if BufferSizeMode=custom, otherwise with BufferSizeMode=driver RS ASIO will just use the currently configured buffer size in your interface/driver, which according to the log, it's configured to be locked at 256 as you can see here: ASIOBufferSize - min: 256 max: 256 preferred: 256 granularity: 0

[oskeith]

Thanks for looking into it and explaining!

I've never needed to restart any hardware (though I have tried); usually restarting RS (possibly more than once) will get the audio working for a brief bit. So when I opened my DAW afterwards it worked fine for the time I tested.

Regarding the BufferSizeMode and CustomBufferSize, I didn't notice when I configured it, but did while debugging, and it hasn't been an issue inthe past. Nonetheless attached is a photo of the interface's ASIO panel when opened from my DAW.

Photo


[mdias]

Usually in this case RS ASIO should unload and reload the driver as the driver is requesting that, but that's a missing feature. Even when the driver does this request you should NOT have to actually restart the hardware or software, the software should just handle it properly (and in this case RS ASIO ignores the restart request).

However even if RS ASIO handled this, it would likely result in audible audio pauses or other similar issues.

It would be interesting to understand the reason the driver is asking for a restart though. Since disabling that "Enable audio enhancements" windows setting seems to work, I would assume windows is trying to do something with the interface that makes it need to restart some state witht the driver or something; perhaps some background application trying to play something that results in changing the sample rate or buffer size, I'm not really sure.

Please feel free to report back if the issue persists even after that change you made, even though I'm not really sure if I'll be able to implement handling of this kind of driver requests any time soon :/

[oskeith]

Hi! I just wanted to give an update on this issue. I haven't played extensively since, but the problem manifested in a new way (with "Enable audio enhancements" off).

I tried playing RS while in a discord call for the first time, with my discord input set to a different mic not through my interface, and output through my interface. I cant remember the exact order of things, but my initial launch of RS had a near immediate audio cutout, and then a relaunch of RS allowed me to play for about 1.5 hours with no issues. However, during that time, the discord input and output cutout and reselecting the input/output settings fixed it. Again, during this time, RS was working fime.

When I was done playing, I hung up the call and exited to the RS main menu, and that's when the audio cut off again. (I think... Checking the log, it doesnt say so, so now I'm doubting myself about the second crash. The first crash definitely happened though as can be seen in the logs.)

immediate crash w discord.txt main menu crash w discord.txt

Thanks!

[mdias]

From your description, it sounds like you have multiple applications fighting over access to the audio interface and your drivers don't handle it very well.

For example, when you launched the game and discord audio cut out, it could be because of ASIO-specific requirements (like bit depth, or sample rate) that didn't meet the current settings in use by discord and so the driver had to re-initialize the audio interface to those settings cutting out the audio streaming that other applications were doing. After that you reset the settings in discord making it use the new current format.

Some audio interfaces/drivers allow regular audio usage through both normal windows audio subsystems and ASIO simultaneously with different audio stream specifications, but not all drivers/interfaces allow this.

This theory also fits relatively well with your previous comments' issues, as any little sound (think windows notification sound, error sound, discord, web browser etc) being played may result in your driver changing the current audio settings and everything else will have it's audio cut. I would expect you to be able to repro this with a DAW too, however any DAW you use will likely be using the 64-bit ASIO drivers while RS ASIO has to use the 32-bit ones (because the game is 32 bit) which may have a different behavior.

[oskeith]

Hmm, that certainly seems possible but I usually turn my computer off when not in use, and I don't usually have other applications open when playing RS. (Last time being an exception with discord, and I realize other background tasks might still intefere.)

However, its worth noting that I've used my interface recording tracks in my DAW for hours, many times with zero issues.

Regardless of whether we find the root cause of this issue, thank you so much for your time looking into this!

[mdias]

One potential test you may be able to do is to disable the audio interface (both inputs and outputs) in windows audio settings. Some ASIO drivers will still work just fine (whole point of ASIO is to not use the windows audio systems and directly communicate with the interface) with that disabled and should prevent non-ASIO software from interfering.

I understand this is probably not a desirable setup even if it works as you'll lose audio on discord etc, but it's worth trying just to see if that's indeed the root cause.

On the chance that your 64-bit ASIO drivers behave well and it's just the 32-bit drivers that are acting weird you can also use a software Voicemeeter that provides it's own ASIO drivers (both 32 and 64 bit) and is able to redirect (when you configure it as such) audio from it's ASIO drivers (32 or 64 bit) to your real interface 64 bit drivers. I've tested this kind of setup in the past with very good success (no noticeable latency or anything like that), but it's annoying as you have to start up the voicemeeter application to get the audio routing going.

Basically you'd configure RS ASIO to use Voicemeeter ASIO driver (for both input and output) and then within Voicemeeter itself you'll be able to specify your real ASIO drivers and route sound etc to/from it.