SDL half sec audio delay

snoop_phone · January 7, 2026, 5:56pm

Hi, I run NetBSD-10.1 on a Le Potato. When using SDL-1.2.15 or 2.32.10 all sound is delayed ~0.6secs. This is completely unfit for playing chocolate-doom (freedoom). It happened also with e.g. picodrive (SDL-1), stella, mplayer (-ao sdl), or my test commandline SDL2 audio program (termbin.com/248g). Other audio, e.g. audiocfg test 0, audioplay, mplayer -ao sun is instant. The SDLs were installed using pkgsrc (with options x11 or also alsa for SDL-2, and none for SDL-1), but i tried SDL-2 from git too, which is same.

Because of this, startup/close of windows is slower too, e.g. chocolate-doom takes longer to display DOS window after quitting game, picodrive takes longer to pause, stella takes longer to start a game, probly because the delayed audio’s still playing.

I tried other SDL_AUDIODRIVERs apart from “netbsd”. Compiling in oss for “dsp” didnt make a diff. Trying “alsa” also (with oss alsa plugin), except that the audio stops faster when the window closes, which is interesting.

The issue isn’t driver buffer size, e.g. for netbsd i could sysctl -w hw.audio0.blk_ms = 10 (default) or = 1 even would not make a diff. For alsa i could set e.g. period_size 512 buffer_size 2048 and same too. Enabling libsamplerate in SDL doesnt fix too (thru env var or chocolate-doom config, which has setting to use libsamplerate). Nor running chocolate-doom as root made a diff.

Also, when using alsa and setting wavSpec.samples=64; or lower in my test program that plays wav files, at first it makes a helicopter sound for a bit before turning into normal sound, during which un/pausing is instant. Like if it was actually capable of playing instant audio somehow? Not sure if matters

I also tried debugging SDL a bit. SDL_PauseAudio() is instant and there’s something in the bg rather delayed. SDL_ResampleAudio() called in the bg (when SDL_AUDIODRIVER=“netbsd”) is instant too, so resampling shouldnt be too slow.

Lastly i checked SDL_EVENT_LOGGING and SDL_LOGGING. When testing chocolate-doom, both on just print about sound (timestamps may be different, but increments of them exactly same (e.g. 2nd is +64 compared to 1st)):

INFO: SDL EVENT: SDL_AUDIODEVICEADDED (timestamp=44 which=0 iscapture=true)
INFO: SDL EVENT: SDL_AUDIODEVICEADDED (timestamp=108 which=1 iscapture=true)
INFO: SDL EVENT: SDL_AUDIODEVICEADDED (timestamp=109 which=0 iscapture=false)
INFO: SDL EVENT: SDL_AUDIODEVICEADDED (timestamp=109 which=1 iscapture=false)

When alsa is on (increments not always same, but 1st timestamp seems same):

INFO: SDL EVENT: SDL_AUDIODEVICEADDED (timestamp=11 which=0 iscapture=true)
INFO: SDL EVENT: SDL_AUDIODEVICEADDED (timestamp=12 which=0 iscapture=false)

Also, i have a USB audio adapter, dmesg:

[ 1249.679846] uaudio0 at uhub2 port 3 configuration 1 interface 0
[ 1249.679846] uaudio0: C-Media Electronics Inc. (0x0d8c) USB Audio Device (0x0014), rev 1.10/1.00, addr 3
[ 1249.679846] uaudio0: audio rev 1.00
[ 1249.679846] audio0 at uaudio0: playback, capture, full duplex, independent
[ 1249.679846] audio0: slinear_le:16 2ch 48000Hz, blk 11520 bytes (60ms) for playback
[ 1249.679846] audio0: slinear_le:16 1ch 48000Hz, blk 6000 bytes (62.5ms) for recording
[ 1249.679846] uhidev3 at uhub2 port 3 configuration 1 interface 3
[ 1249.679846] uhidev3: C-Media Electronics Inc. (0x0d8c) USB Audio Device (0x0014), rev 1.10/1.00, addr 3, iclass 3/0
[ 1249.679846] uhid4 at uhidev3: input=4, output=4, feature=0

Idk what to do to fix this. Can someone help? Thank you!

snoop_phone · January 25, 2026, 12:00pm

Setting SDL_AUDIODRIVER=”disk” and playing the file (tail -f -n 9999999 sdlaudio.raw | audioplay -f -e slinear_le -c 2 -P 16 -s 44100) during playing chocolate-doom also had the delay.

Also some programs are weirdly slown down too, e.g. stella is slow/laggy, also vice, licar, anarch (but not chocolate-doom). Not sure if matters or related with this delay

Sward · January 25, 2026, 9:50pm

I have a couple of questions/tests:

Try checking the CPU and RAM use while running the programs that lag, is there anything at or near 100% usage while those programs are running and lagging?
Is the SOC perhaps dusty and building up heat?
Try a different power supply and line, sometimes the usb cable gets old and can’t provide the 1.5+ amps required by the system. (If Le Potato acts the same as a Raspberry Pi in this situation, the system doesn’t exactly shut down, but must operate in a reduced capacity.)
Have you tried running with a Linux version to see if it runs better? (Would help to pin it down to a NetBSD issue)
I see some saying that NetBSD 9 runs more smoothly than NetBSD 10 on Le Potato, perhaps try the older version to see if this helps.
What desktop environment are you running, could you try a lighter one?

From what I’m reading online, all versions of SDL are considered to be very well supported on NetBSD, the audio APIs being noted as especially good. This leads me to believe the issues are being caused by NetBSD 10’s interaction with Le Potato (low hardware specs, low power input, or bad drivers). So I hope something in the above list might improve the situation for you.

snoop_phone · January 26, 2026, 11:06am

Hi, thank you, my responses to these tests/questions are below:

chocolate-doom runs ok but CPU i thought it was ~10%? when testing once but now i see rising even to 100+%, and 115M, as for stella first launcher 86M 0% CPU or ~2.5 at first then game 118M CPU high rising again to similar %. Hm. But picodrive (SDL1 but also delayed sound) with sonic 1 game goes sometimes ~5% sometimes up to 25% too. Once jumped to 75% even. Did i mention that once when using NetBSD-9.4 all games were stuttering too including glxgears but with 10.1 update it started at first then magically fixed.
Shouldn’t be, also it’s kinda new (got computer few months ago) and has a libre blue heatsink, so shouldnt be bad
I just use long cable connected to big phone charging block, but i didnt ever see red LED blinking
No i didnt try Lunix, maybe I could later if needed
I had NetBSD-9.4 here once and updated it via source (except the bad 10.1 dtb (e.g. doesnt see usb keyboard), which may be reason why 9.4 is more often used), so my usb sound works which didnt with 9.4.
dwm with X, term is st, I dont think theres anything lighter. But the res is huge 1920x1080 and i wanted to change it to be lower, but idk how right now (u-boot would probly need hardcoding).

Also yea NetBSD has some missing drivers for le potato such as gpu and audio (even hdmi and jack, except some simple amplifier which i added to dtb and idk if it works), which is why im using a usb adapter, which has its own soundcard though. But NetBSD should work well with low-spec machines

Sward · January 26, 2026, 5:09pm

I decided to research this further, I’m sorry if some of it is superfluous.

What happens if you run Chocolate Doom at 2x scale or 3x scale rather than fullscreen?
(the command-line argument should be -2 or -3 respectively)
1.a. Chocolate Doom’s original engine only provides a 320x200 8 bit image, SDL is then in charge of scaling the original image in size and to 32 bit mode, some users have reported experiencing the lag only in fullscreen.
1.b. As far as I understand it, this is because Chocolate Doom runs in CPU graphics mode rather than on the GPU. Some efforts were made to establish a GPU mode, but I haven’t found evidence of that actually being implemented.
It looks like the NetBSD guys fixed the USB and some C driver issues in the up-coming NetBSD 11 daily build (The Libre Computer Board specific build). It might be worth upgrading to this slightly experimental version of NetBSD 11?
Here’s the forum that I found this information: NetBSD can be used on 'Potato' - #12 by granowski - Software - Libre Computer Hub
Here’s the link to the board specific daily builds: NetBSD Arm Bootable Images
Is your current OS version a board-specific build, or the generic arm build?

snoop_phone · January 26, 2026, 7:34pm

1. I was already running it -3, but i remember fullscreen was similar fps. I try fullscreen now and it actually seems laggier while cpu rising to 100+% again. wait what i switched back to workspace with chocolate-doom and it resized from fullscreen to slightly bigger than -3 (like the window which was at first flashing when starting the game), weird

1.a. I also try -1 and cpu seems to rise slower it went to 25% then later 40. for -2 rises to 60%, also 75%. but sound’s still same. seems like bigger window=more cpu. Note that picodrive window size was similar to -1. And I test licar with X11 only no SDL 960x720 (similar to -3) window and rises to 40% cpu when viewing a replay, 640x480 (similar to -2) 30%.

1.b. Yea chocolate-doom is sw-rendering only which is very nice. Maybe that’s why it didnt lag while other games did, because maybe it has its own rendering? Earlier also other progs like stella said that some video driver is not available and then i’d need to SDL_VIDEODRIVER=”software” which doesnt happen now for some reason but chocolate-doom never did that (even though it reacts when SDL_VIDEODRIVER is e.g. wrong). Maybe SDL is delayed in general

2. So they fixed the dtb? I was already using a fixed dtb for 10.1 but i could look into 11 to see if it has more things for le pot, or maybe also try its kernel, even though it’s still unfinished

3. I think it was the le potato build, which had seemingly no diffs with the arm generic one, but idk if it matters now if i upgraded from source to 10.1.

Also im trying to find out rn how to change the res (asking on irc), not sure if i’ll succeed.

Sward · January 26, 2026, 7:43pm

Check out XRandr for changing the screen resolution from console/terminal, it should be available in your package manager if it’s not installed by default.

snoop_phone · January 26, 2026, 7:54pm

Thank you but i tried once and didnt work, it errored about some crc 0 which i think means gpu, which is gone.

Sward · January 26, 2026, 11:54pm

It sounds like the resolution you were requesting might not be supported by the screen. Or it might be some other issue. There is a command in xrandr to show all supported resolutions.

Maybe try arandr which is a gui wrapper for xrandr.

Launch arandr, then go to outputs->HDMI-1->resolution->1280x720
Once you have selected a change, hit the big checkmark.
(HDMI-1 may be a different name, but it should indicate the name of your screen output port)
These changes are not persistent, so if you find yourself in a position where screen elements are not reachable, just reboot.

snoop_phone · January 27, 2026, 9:01am

I cant seem to install arandr because of dependency issues. But xrandr should work normally if arandr would right?
I run xrandr like this: termbin.com/iwf3 so i add a new resolution because else only 1920x1080 is available and setting to it flashes term and errors about crtc 0 (not crc 0)

snoop_phone · February 9, 2026, 9:32pm

Ok I finally got 1280x720 by finding out how to hardcode the res in u-boot. But audio delay’s same. I try chocolate-doom -1 and top says almost 30%CPU. also glxgears on half screen does almost 70fps when earlier it’d probly do ~30.

I even tried 720x480 res and same delay and cpu.

snoop_phone · February 19, 2026, 6:36pm

I updated to NetBSD 11.0 RC1 (with my prev dtb because new doesnt work) and theres no diff to sound too