Poor audio on OpenBSD

[bentley]

When playing games on OpenBSD with the SDL2 frontend, audio has lots of clicks and noises, and emulation is noticeably slower than it should be.

Attached are audio recordings of (version 0.12.3 of) the SDL frontend and of the libretro core running under RetroArch, which does not have these issues. The clicks and slowness in the SDL recording are representative of what you hear during normal gameplay. The clicks in the libretro recording seem to be artifacts of the recording—nothing similar is audible when playing normally.

openbsd-audio.zip

[LIJI32]

Sadly, if it only reproduces on OpenBSD and not other frontends, it's most likely an SDL2 bug that I pretty much don't have any means to fix. SDL2 audio turned out to be very buggy over SameBoy's development, with newer versions of SDL2 breaking some audio configurations on macOS and Linux, but I don't know any better cross-platform alternative. Can you try with different (Newer or older) versions of SDL2 and see if it has any effect? If so, it might be more effective to report it the SDL folks.

[LIJI32]

I pushed a branch with a port-audio driver for the SDL frontend. Sadly, it seems to be completely broken on ALSA on Linux, but maybe it performs better on OpenBSD. Let me know.

[bentley]

Thanks for checking. I built and ran the portaudio and SDL audio backends, but couldn’t distinguish any difference in sound quality between them: both had serious clicking along with slow emulation.

There were two differences in the portaudio version: bringing up the menu with Esc had noticeable delay, and hitting ^C during emulation triggered a crash:

#0  0x00000d6071d63510 in memcpy (dst0=<optimized out>, src0=<optimized out>, 
    length=3840) at /usr/src/lib/libc/string/memcpy.c:103
#1  0x00000d5e3cd2f321 in callback (in=0x0, _out=0xd611131b100, frames=960, 
    time_info=0xd60b0eab108, status_flags=0, unused=0x0)
    at SDL/audio/portaudio.c:113
#2  0x00000d6107676f41 in NonAdaptingProcess ()
   from /usr/local/lib/libportaudio.so.1.2
#3  0x00000d6107676927 in PaUtil_EndBufferProcessing ()
   from /usr/local/lib/libportaudio.so.1.2
#4  0x00000d610767a0d3 in sndioThread ()
   from /usr/local/lib/libportaudio.so.1.2
#5  0x00000d6062b4b811 in _rthread_start (v=<optimized out>)
    at /usr/src/lib/librthread/rthread.c:96
#6  0x00000d6071d743d8 in __tfork_thread ()
    at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:77
#7  0x0000000000000000 in ?? ()

[LIJI32]

After countless experiments that all performed flawlessly on macOS but failed horribly on Linux with ALSA (and I assume it'll behave the same on OpenBSD), I have to drop this issue. It appears that portaudio on ALSA is simply incapable of producing reasonable quality audio, and my previous experience with reporting bugs to SDL2 shows that the SDL2 team are neither incapable or unwilling to fix the countless audio regressions they've had since 2.0.5. Moreover, it has been reported to me that merely running an SDL app in the background without any sound has a negative effect on system-wide audio quality. The other Linux/BSD audio APIs I found either wrap SDL2, aren't portable enough (If I use the PulseAudio API it won't work on JACK systems), or plain horrible (OpenAL).

Other than downgrading to SDL 2.0.4, there are two possible long term solutions:

1. I cherrypicked the abstraction of the audio APIs, if anyone wishes to contibute an alternative audio driver, they're welcome.
2. @max-m is working on a GTK frontend that appears to work well with at least one revision of my portaudio driver. This frontend will eventually deprecate the SDL port completely.

Sorry, but that's as much as I can do.

[LIJI32]

Turns out the GTK frontend has audio issues on other machines, so the only solution is to wait for someone to contribute another audio driver. =/

[m1o1]

I've heard these clicks in pokemon tcg in places like the rock club. Using Ubuntu 20.04. I assume it's the same issue as here but figured I could give another test case.