Audio lag using OMX plugin

[rcork]

There is a noticeable lag when using the OMX audio plugin that doesn't happen when using SDL. It appears to be about 500ms. I'm using mupen64plus 2.5 on a Raspberry Pi 2 with Retropie 3.2.1

[Audio-OMX]

# Mupen64Plus OMX Audio Plugin config parameter version number
Version = 1
# Frequency which is used if rom doesn't want to change it
DEFAULT_FREQUENCY = 33600
# Swaps left and right channels
SWAP_CHANNELS = False
# Audio output to go to (0) Analogue jack, (1) HDMI
OUTPUT_PORT = 1
# Point OMX to the raw N64 audio data region instead of copying audio int$
NATIVE_MODE = True
# Number of output samples per Audio callback. This is for hardware buffe$
BUFFER_SIZE = 2048
# Audio Output Frequncy mode (when NATIVE_MODE=false): 0 = Rom Frequency,$
DEFAULT_MODE = 1
# Desired Latency in ms
LATENCY = 220
# Underrun Mode, 0 = Ignore, 1 = Report, 2 = repeat audio when latency < $
UNDERRUN_MODE = 0

[gizmo98]

I don't know what is wrong with your setup. I'm really sure native mode is disabled by default.

[ricrpi]

It is, in fact the setting is hidden unless you build with a -D compiler option.

Native mode points the omx hardware at the raw audio data in the emulated memory (as opposed to having it resampled) as soon as the emulated Audio Interrupt is fired. Therefore any delay is not going to be from the audio plugin.

[rcork]

So are you saying I need to compile from source using -D and then native mode should be set to true?

[ricrpi]

No, Native mode should be False as most N64 game frequencies do not use standard HDMI frequencies.

The plugin asks your TV if the non-standard frequency is supported ( see InitializeAudio() ) but some TV's don't report correctly. This leads to bad audio distortions on my TV.

As Native mode makes <1% difference in performance, I decided to hide if from the standard cfg.

I would recommend you ensure you have the latest code and delete the omx-audio cfg section so that a new default is written. It could be a non-standard frequency is making your TV do strange things as well.

[rcork]

So i've tried several approaches (all on a Raspberry Pi 2)

1. Retropie 3.2.1 - SD image with precompiled mupen64plus binary
2. Raspbian with Retropie script to install precompiled mupen64plus binary
3. Compiled mupen64plus from source on Raspbian

I still see about 500ms lag in audio output. I've tested with multiple televisions, directly or through an AV receiver, it makes no difference. If i switch to use SDL audio, there is no lag. However, SDL causes issues with the rice video plugin which i require for several games.

[rcork]

Ok i continue to dig into this. I found that if i use the mupen64plus that ships in binary form with RetroPie 3.2.1, audio is fine. No lag. However, the version that ship suffers from a bug where loading game state on an RPi2 crashes mupen with an alignment exception. Compiling mupen from source fixes this issue but introduces the audio lag with OMX.

[gizmo98]

Do all video plugins have audio lag? Could be a rice problem.

[ricrpi]

Is the core your using version 2.5?

A number of changes where made for 2.5 which affect audio significantly. I haven't checked that the omx plugin is still compatible...

[rcork]

@gizmo98 Both rice and gles2n64 both have lag. I haven't tried Glide.

@ricrpi Yes, the version that Retropie compiles if you choose the source option (which i did to solve the alignment exception issue when loading game state) is 2.5

[rcork]

@gizmo98's changes here seems to have fixed the issue: https://github.com/RetroPie/RetroPie-Setup/commit/04e7209ce3da908a082f01abb533f0626aaa02c9

[ricrpi]

Very interesting results,

@gizmo98 Could you push your changes into this repo please?

[gizmo98]

It's a hot fix at the moment. I will push it upstream if i have tested a little bit more.

BR gizmo