The mistery with low latency audio on GNU/LInux

RetroArch Linux devices
#1

Hi there,

On the news on the Libretro front page, I can read:

“Audio latency can also be driven down significantly now with Vulkan. Theccurrent default is 128ms, with Vulkan we can drive it down to 64 or even 32ms.”

That’s for Vulkan+Android devices. On GNU/Linux, I have found that: -On my X86_64 i3 laptop running my own barebones GNU/Linux system with 4.9 kernel, no matter what latency setting I specify, using KMS/DRM mode, latency does not change. Must be the ALSA driver on the system. -On the Raspberry Pi 3, using a triple buffering video rendering system (GLES on dispmanx, or direct-dispmanx with a triple buffering) I can go down to 32ms audio latency, with no apparent popping/crackling (ie: no buffer underruns on the “ALSA” backend) However, if I use a double buffering video (dispmanx with double buffering is the only option here, since there’s no way to do double-buffered EGL on the Pi with the BCM graphisc stack),going down to 32ms starts causing popping and crackling while CPU usage is LOW (~30% of a single core for NeoGeo games).

So, with a low CPU usage, why is 32ms audio latency causing ALSA buffer underruns if I use double-buffered video but not if I use triple-buffered video? I can guess there’s some kind of system jittering at play, but I tried an RT-patched kernel, played around with the chrt settings on RetroArch (yes, I have modified my system so I can do so without being root), and got no differences…

Using ALSA (no “ALSATHREAD”) driver here. ALSATHREAD shows way more distorted audio with double-buffered video + 32ms latency.

Any ideas are welcome.

#2

On my Nvidia Shield, I can get 16 ms comfortably with Vulkan.

I’ve also gotten down to single-digit latency with JACK, if you can try that.

#3

@hunterk: Are you sure the 16ms setting is being applied? I can get down to 8ms on my i3 but it’s only an illusion, since real latency doesn’t vary between 8ms and the maximum ~500ms.

Also, how many buffers is the video driver using? GLES uses 3 by default. The only double-buffered driver are GLES/GL on KMS/DRM with max_swapchain=2, and dispmanx.

#4

Dunno. How are you measuring the actual latency to know whether it’s actually as low (or not) as it claims?

I set max_swapchain to 1 with Vulkan.

#5

Setting max_swapchain should cause tearing or not work at all, since there’s only one buffer (the one on screen) so writting to it must be visible. If you don’t see tearing, then you’re probably using 2+ buffers actually, as far as I understand. As for audio latency, I can perceive how it changes between, let’s say, 32ms and the maximum value.

#6

I get a visible tear in the menus when scrolling vertically but I don’t notice any tearing in-game. I’ll try to play with it some this evening and see if I can pin anything down.