Trying to lower audio latency without artifacts (GL/ALSA)

RetroArch General
#1

HI there,

I was doing some experiments yesterday regarding audio latency with RetroArch. Similar results can be seen on GNU/Linux on both desktop-class i5 PC (KMS/DRM+GLES / Alsathread) and Raspberry Pi (Dispmanx+GLES / Alsathread ), so I guess they are aplicable to any GNU/Linux system with a decent ALSA and GLES implementation.

Thing is, if I set “Dynamic Audio Rate Control” to 0.000, I can set “Audio Latency” to a value as low as 16ms with no video problems at all and no audio dropouts, only some occasional crackling because of the lack of…well, dynamic audio rate control. Of couse, I can set a higher “Audio Latency” value, but as long as I have “Dynamic Audio Rate Control” set to 0.000, I WILL have occasional crackling anyway. That’s to be expectec.

“Dynamic Audio Rate Control” is a very good general solution, but, how could I get rid of the cracking without it? I take it corrects the audio resampling frequency “on the fly” to compensate the physical vsync frequency fluctuations, so… should it be possible to build a kernel with next-to-zero physical vsync frequency fluctuations so “Dynamic Audio Rate Control” becomes un-needed?

PD: I am already running the RetroArch process in isolated cores (isolcpus) that NEVER receive an interrupt when RetroArch is not running on them. No background services either.

#2

You could manually set the sample rate to a specific value that would correspond to your monitor’s actual refresh rate. This is how Higan used to do it. If you’re very meticulous, you can get it down to one crackle every 10-30 min.

I believe you should be able to get sub-8 ms latency with JACK, even with DRC enabled.

#3

Yes, I remember that option in Higan before I discovered the wonders of RetroArch and it’s automatic rate control, years ago.

What sample rate do you mean? Some cores have their own “internal” sample rate value option, but for others there’s only the general/final-output “Audio Output Rate” in the RetroArch audio settings. So I believe you mean the RetroArch final audio rate, but that does not make much sense in my head: the problem is not the output audio frequency, but the internal core frequency, as it can generate too many or too few samples-per-second to accomodate a given physical vsync frequency. How would you do the calculations anyway? I used to consider the snes to be 60.09/32000 natively and adjust from there, but again, 32040 is the internal core audio freq and not the external audio freq. (In fact, I can’t even find a precisse snes video rate value…) EDIT: Seems that snes is 60.09881389744051 Hz video and 32040 Hz audio, but the question about what RetroArch audio freq do you mean remains.

The thing with Jack is that, as far as I know, it runs ON ALSA, so I never saw it giving stable lower “Audio Latency” values with or without DRC enabled, so I am reluctant to go that experimentation route.

Also, I am perceiving that a DRC of 0.001 will allow lower stable “Audio Latency” values than, let’s say, a DRC of 0.005. Am I right on this?

#4

@hunterk: any input to my questions, please? :wink:

#5

Yeah, I did mean RetroArch’s output rate but I think you would also need to set the audio_resampler to “nul” or “” in your retroarch.cfg. Tbh, I dunno if it’ll do what I’m expecting. I haven’t tried it.

As for DRC 0.001 vs 0.005, I don’t think that will have an effect, as it’'s only telling it how much it’s allowed to deviate the pitch, but it’s worth checking out.

#6

@hunterk: The thing is, setting the resampler to null or “” in my cfg makes RetroArch go totally silent. Is that supposed to work?

#7

my hope was that it would avoid resampling the audio and just push out the raw core audio. guess not.

#8

So, no way to simply disable the resampler yet having sound?

#9

not that I know of. It shouldn’t be a major source of latency anyway, but you can try some of the lower-quality resamplers and see if it improves.