Walnut Games

All games

dsda-doom

Gold · 90 with DSDA-Doom (OpenGL) 0.1 h played, 0 crashes

A Doom source port with an OpenGL renderer, accurate demo playback and many mod features.

Genre
shooter first-person
Players
single player
Input
made for keyboard and mouse
View
first-person
Content
mods
Engine
id Tech 1 DSDA-Doom

Played sessions

Testing is done with Walnut's rating tool (walnut-rate, on the console): how ratings are made and submitted.

Same in every session: Walnut 0.1, dsda-doom 0.30.0+dfsg-1+ps3.786

The platform builds under it (3)
Linux kernel6.12.111+ps3.747 Walnut's build
Mesa26.2.4-1+ps3.721 Walnut's build
ps3rsx0.735+k6.12.111+ps3.747 Walnut's build
DateLauncherRulesPlayEndedPicture
2026-10-25 DSDA-Doom (software) 1.07 minquit ok Details
2026-10-25 DSDA-Doom (OpenGL) 1.09 minquit ok Details

Download all sessions as CSV (one row per session, the aspects as columns)

Rating history

The rating on each version it was tested on, newest first: each row is rated from that version's sessions alone, under the newest rules those sessions have the data for.

DSDA-Doom (OpenGL)

VersionTestedMedalRules Frame rateSmoothnessSoundPictureStabilityDisplayLoad Play
Walnut 0.1
dsda-doom 0.30.0+dfsg-1		 2026-10-25 Gold · 90 1.0 89897710091-100 0.1 h
1 test

DSDA-Doom (software)

VersionTestedMedalRules Frame rateSmoothnessSoundPictureStabilityDisplayLoad Play
Walnut 0.1
dsda-doom 0.30.0+dfsg-1		 2026-10-25 Silver · 71 1.0 45735210090-100 0.1 h
1 test

Scripted benchmarks

Not rated: tests of driver and game changes. A script plays the same scene on the PS3 again and again (the desktop stopped, vsync off) to compare two builds of the game or of the graphics driver. The numbers say which build is faster; they never feed the medal.

How the script plays it: dsda-doom 0.30.0 + Freedoom 2: timedemo of Freedoom's own DEMO1 lump, fullscreen 1920x1080.

The recipe's full description

dsda-doom 0.30.0 + Freedoom 2 (stands in for PrBoom+ GL): timedemo of Freedoom's own DEMO1 lump, fullscreen 1920x1080. Software renderer first (base, safest), GL as a variant: GL mode uploads indexed textures as GL_RG, which nv30 lacks (the game's technical.md), so expect missing textures there. Steady state: passes. DEMO1 is 2664 gametics (76 s at 35 Hz; the timedemo takes ~54 s at 49 fps). Stock dsda-doom exits at a timedemo's end (dsda_demo_end_quit), so our patch 0006 (g_game.c, the timingdemo branch of G_CheckDemoStatus) repeats it: DSDA_BENCH_LOOPS=N passes, each with its own gametics and realtics and its own "Timed ..." line. 6 passes of ~54 s cover 60 s of warm-up and 120 s counted; slower passes (the PS3) end the run earlier, the client stops it once enough is measured. fps= is the first pass's, as before.

21 variants of the recipe
basethe recipe as it is, without a variant
gl stands for the game-
owncfgbase (the software renderer, 960x540 scaled to the screen: the menu's "DSDA-Doom (software)") on a config of the run's own: -config in the run directory, nonexistent at the start, so dsda-doom's defaults (FluidSynth music, 44.1 kHz) and nothing of the player's dsda-doom.cfg read or written; the CPU-bound case of the real-time audio tests (docs/SPU-AUDIO.md "Real-time mixer")
sw1080-
glesSDL's GLES2 renderer instead of its desktop-GL one (the software frame goes to the screen through an SDL texture): the 960x540 software run was green-tinted
sdlswSDL's software renderer: no GL at all in presenting the frame (tells a GPU-path colour bug from the game's or SDL's own)
playthe demo at normal speed (35 tics/s, as in play) with the GL renderer: does the sound keep up when the game isn't rendering flat out? (60 s, HUD fps)
playnomusicplay without the MIDI music (fluidsynth synthesizes it in software on the PPE): effects only
tunedsound tuning for the PPE, music on (plain play stuttered: fluidsynth took ~40% of a thread and rendering ran uncapped): OPL music emulation (snd_midiplayer "opl"), mixing at the device's 48 kHz (no resampling), a larger buffer, frames capped at 60
playoplone sound setting at a time against the underrun count (bench.txt underruns=)
playcap35-
play48k-
playspufluidsynth's voice DSP on the SPEs (our libfluidsynth3 +ps3.289 with libspeq0 0.288, docs/SPU-AUDIO.md "fluidsynth on the SPEs"): spu always, ppe = libspeq's code on the PPE, off = stock fluidsynth
playppe-
playoff-
glstatsGL renderer draws (our patch 0005, gl_batch.c): walls, flats, sprites and HUD patches batched into few glDrawArrays, light level per vertex. On the host (llvmpipe, GL 2.1) the gl timedemo goes from ~1960 GL calls and ~205 draws a frame to ~390 and ~46. Each switch alone, all off (= the renderer before 0005), and the per-frame batch counts in game.log every 350 frames
glnobatch-
glnoflats-
glnohud-
glnovlight-
gloff-

One table, a header row per batch (what it tested and what came out). Conditions: what a variant adds to the recipe (its environment switches) and what ran alongside (the stall recorder, a profiler); a column appears only when this game has a value in it. Rows marked invalid or not comparable say why.

What the run length means

"warm-up + 120 s" is a steady-state run, which leaves out a 60 s warm-up and measures 120 s or more; "whole run" counted everything from the start, the way runs before 2026-10-17 did.

Variant Conditions Steady fps
in the window		 1% low
fps		 Stalls
frames over 100 ms		 fps
whole run		 Build Run length ram free
MiB		vram
MiB		stall play s
seconds		longest play ms
ms		sound faults per min
faults a minute		cpu
seconds		underruns
underruns		longest ms
ms		 Note
Suite summary 2026-10-20 · suite-summary-2026-10
Tested: Not a test run: the suite's 13 benchmarked games (15 rows, with OpenArena's two renderers and OpenTTD's two blitters) gathered with their known numbers as of October 2026, each value naming the batch or document it came from.
Result: It is the calibration of the rating formula (rules 1): the scale was tried on these numbers before any game was rated, and the GameDB calibration table is generated from it. Benchmarks never give a medal; medals come from played sessions only.
dsda-doom the recipe as it is 55.9 40.3 - - - warm-up + 120 s 43 65 0.0 34 465 - - - right, music chops
Real-time audio as shipped: ps3-desktop 0.1013 (limits.d rtprio 10 + ps3-rt-audio, RTAUDIO=1) against none (RTPRIO=0) on dsda-doom software (owncfg), Extreme Tux Racer, X-Moto and Neverball (kernel .874) 2026-10-28 · 2026-10-28-rt-audio-shipped
Tested: Real-time audio as shipped in ps3-desktop 0.1013 (a priority limit plus ps3-rt-audio, which game mode uses to put the game's audio thread on SCHED_RR), against none, on dsda-doom, Extreme Tux Racer, X-Moto and Neverball.
Result: Shipped. Audible dropouts a run fell from 29 to 2 in dsda-doom, 26 to 2 in Extreme Tux Racer and 3 to 0 in Neverball, with steady fps unchanged within 0.4%. The 1% lows came out a little lower in the light games, with the ranges touching.
What we saw

25 runs in three rounds, games interleaved, arm order alternating. Two Neverball runs with it were interfered by the agent's own SSH checks and left out, so Neverball has 2 runs with it. Every run fullscreen at 1920x1080 and in gameplay at its 40 s screenshot.

  • ps3-rt-audio put the audio thread on SCHED_RR 1 in every run with it: SDL's audio thread in dsda-doom, X-Moto and Neverball, and Extreme Tux Racer's unnamed audio thread.
  • Audible dropouts a run (about 200 s), median, without and with it: dsda-doom 29 to 2 (audible time 0.8-1.2 s to 50-113 ms), Extreme Tux Racer 26 to 2 (0.65-0.92 s to 58-124 ms), Neverball 3 to 0, X-Moto 0 to 0 (logged underruns 78 to 11).
  • Steady fps unchanged within 0.4%: dsda-doom 39.75 and 39.8, X-Moto 161.7 and 161.0, Neverball 82.73 and 82.72.
  • 1% lows a little lower with it in the light games, ranges touching: X-Moto 113.4 to 109.4, Neverball 57.9 to 56.6, dsda-doom 20.6 to 19.0.
  • Extreme Tux Racer's were higher with it: HUD 1% low 19.8 to 29.2, steady 56 to 59. The previous batch had no such gap (29.9 against 28.6).
owncfg rtaudio 39.8 19.4 0 37.5 - warm-up + 120 s 43.2 25.7 0.0 87.1 - 283.6 3436 104.0
owncfg real-time priority 0 39.8 21.0 1 37.7 - warm-up + 120 s 39.9 25.7 0.1 104.3 - 281.6 4290 109.9
RT audio thread: SCHED_RR 1 from outside (RTPRIO=10+RTTHREAD) and nice -20 (NICELIM=40) against none on dsda-doom software (owncfg), Extreme Tux Racer and OpenTTD (kernel .874) 2026-10-28 · 2026-10-28-rt-audio-thread
Tested: Whether putting the game's own audio thread on real-time priority (SCHED_RR 1, set from outside) or running the game at nice -20 stops the audible dropouts in dsda-doom (software renderer), Extreme Tux Racer and OpenTTD.
Result: SCHED_RR clearly helps: median dropouts a run fell from 19 to 2 in dsda-doom and from 24 to 3.5 in Extreme Tux Racer, at no frame-rate cost. nice -20 helped less and cost dsda-doom 2%. A per-game opt-in was recommended; not shipped in this form.
What we saw

38 runs in four rounds, order rotated. 14 were interfered by another agent's SSH logins and left out. Every counted run was fullscreen at 1920x1080 and in gameplay at its 40 s screenshot.

  • Audible dropouts a run (about 200 s), median. dsda-doom: 19 with nothing, 10.5 with nice -20, 2 with SCHED_RR.
  • Extreme Tux Racer: 24 with nothing, 3.5 with SCHED_RR.
  • OpenTTD: 2 with nothing (2 clean runs), 1 with nice -20; logged underruns 2019 to 1095.
  • No fps cost from SCHED_RR beyond the noise: dsda-doom 40.1 against 40.3, Extreme Tux Racer 59 against 59. nice -20 cost dsda-doom 2% of its steady fps and two points of 1% low.
  • SDL's own real-time hint does nothing without RTKit: the thread stayed at normal priority.
owncfg nicelim40 39.7 19.9 1.0 38.0 - warm-up + 120 s 43.6 25.7 0.1 105.6 - 284.1 3887.5 106.8
owncfg real-time priority 0 40.3 21.7 0 38.9 - warm-up + 120 s 41.4 25.7 0.0 71.2 - 279.2 4217 83.0
owncfg real-time priority 10
switch rtthread		 40.1 21.2 0 38.5 - warm-up + 120 s 43.5 25.7 0.0 77.7 - 279.2 3487 113.9
batch ssdroot2 P1b: gameplay profiles on the SSD root (PERF=1 MEM=1 x1) 2026-10-19 · 2026-10-19-ssdroot2-gameplay-profiles
Tested: Where the CPU goes during play in seven games on the SSD root, profiled with perf over the measured window.
Result: Mesa is the biggest share in BananaBread (62.8%) and ClassiCube, the game itself in SuperTuxKart, OpenArena and Luanti, and OpenTTD spends half its time in the kernel. Profiled runs, not for frame rates; OpenTTD was profiled at its title screen, not in play.
What we saw
  • Same boot, one run per game, perf at 499 Hz over the window. Profiled runs are for profiles, not fps (OpenArena 56 against 60 unprofiled).
  • Share of the game process's samples:
  • BananaBread: Mesa 62.8%, the GPU kernel driver 4.8, the game 10.5.
  • ClassiCube: Mesa 41.2, kernel 20.1, the GPU kernel driver 7.1.
  • SuperTuxKart: the game 36.5, Mesa 35.5, libc 15.1.
  • OpenArena: the game 27.6, Mesa 23.1, other 20.4 (OpenAL 12.4, libdeflate 3.9).
  • Luanti: the game 47.2 (its mesh-update thread 20.7% of all samples), Mesa 14.6, libc 13.7.
  • dsda-doom: Mesa 22.3, the game 20.5, audio 30 (FluidSynth 15, libspeq 12).
  • OpenTTD: kernel 49.5 (36.7 replaying deferred interrupts, 8.3 page table invalidation, 5.1 clearing GPU memory mappings when buffers are created), audio 17. It ran at its title screen (a menu, not gameplay: 18 fps, 4172 underruns).
  • Mesa has no symbols in these profiles (to be resolved on the PC later). SuperTuxKart's fps is the HUD's.

not comparable gameplay profiles (PERF=1 MEM=1), slower than plain runs.
gl
not comparable		 perf recording 55.9 39.7 0 55.7 - warm-up + 120 s 43.1 64.9 0.0 42.4 - 131.3 2793 42.4
batch 8: STK lean, OpenTTD gl, ClassiCube/dsda batching, malloc presets, profiles (Mesa ps3.408, kick) 2026-10-18 · 2026-10-18-batch8
Tested: A mixed batch: SuperTuxKart's lean settings, OpenTTD's OpenGL driver, draw batching in ClassiCube and dsda-doom, memory allocator presets, and profiles of OpenArena and Luanti.
Result: SuperTuxKart lean runs 21.4 fps against 13 with far fewer stalls, OpenTTD's GL driver doubles its frame rate, dsda-doom's batching gains 3% while ClassiCube's loses 4%, and the allocator presets were noise. One Luanti profiling run was disturbed by a mouse click.
What we saw
  • Same boot.
  • SuperTuxKart: the track draws (webcam). Lean settings 21.4 fps smooth against 13 as built, stalls 2.4 against 13.5 s.
  • OpenTTD with the GL driver: right picture, 21 fps (8-12 with software drawing).
  • ClassiCube with batching 47.3 fps against 49.4 with the old drawing (-4%), but 1% low 31 against 27.6.
  • dsda-doom GL renderer with batching 55.9 against 54.2 (+3%), 1% low 40.8 against 36.5.
  • Memory allocator presets: inconsistent between rounds (noise).
  • OpenArena OpenGL 2 renderer: 55 s of stalls, longest 16 s, 66 MB swapped out. Luanti: 10 s of stalls, 51 MB swapped out.
  • Interference (found by the later scan): the profiled Luanti run had a right click in its measured window, so distrust that cell.
gl waker kick at 10 ms 55.9 40.3 0.0 54.7 Mesa ps3.408 warm-up + 120 s 43.3 64.9 0.0 34.4 - 117.9 2101.0 42.5
gloff DSDA_GL_BATCH=0
DSDA_GL_FLATS=0
DSDA_GL_HUD=0
DSDA_GL_VLIGHT=0
waker kick at 10 ms		 54.2 36.4 0.0 53.0 Mesa ps3.408 warm-up + 120 s 44.0 64.8 0.0 67.7 - 161.1 2668.5 67.7
Mesa ps3.407 switches (QuakeSpasm LUT, ClassiCube fence pool), profiler checks (ps3-gpu-tools 0.412), all with WAKER kick 2026-10-18 · 2026-10-18-mesa-407-switches
Tested: Two more Mesa ps3.407 switches (the vertex lookup table on QuakeSpasm, a fence pool on ClassiCube), plus profile checks of dsda-doom, OpenTTD and Armagetron with ps3-gpu-tools 0.412.
Result: Both switches are neutral: QuakeSpasm keeps 91 fps with about 3% less CPU, ClassiCube is identical. The Armagetron run is invalid (it sat in the language menu).
What we saw
  • Same boot, all with the 10 ms waker kick.
  • QuakeSpasm with the lookup table: steady 91.0 and 90.8 fps against 90.9 and 91.0 without (no change). CPU 104 and 101 s against 108 and 106 (about -3%).
  • ClassiCube with a pool of 16 fence buffers: identical (48.4 fps).
  • dsda-doom profile fine: 40.3 fps steady, no stalls.
  • OpenTTD reached its title game without the survey dialog (webcam OK).
  • Armagetron: invalid. It was stuck at the first-start language menu (webcam); its 183 fps is the menu.
base waker kick at 10 ms
perf recording		 40.3 21.8 0 40.3 Mesa ps3.407 warm-up + 120 s 45.4 25.7 0.0 96.6 - 271.0 4089 96.6
libspeq 0.367 (shared deadline pool), fluidsynth ps3.309, dsda-doom ps3.361 2026-10-17 · 2026-10-17-speq-367-deadline-pool
Tested: libspeq 0.367, where the SPU work runs on a shared pool of two SPUs with deadlines, on dsda-doom's FluidSynth music.
Result: The synth ran fully on the SPUs with no timeouts, and underruns fell to 465 against 1095 with the synth on the PPE.
What we saw

Same boot, 60 s runs with music. The synth ran on the two-SPU pool: 4530 rounds on the SPUs, 0 timeouts, 0.84 ms mean wait. ALSA underruns: 465 with the SPUs against 1095 on the PPE. Picture right on the webcam.

playppe SPEQ_SYNTH=ppe
SPEQ_DEBUG=1		 - - - 57 - whole run 37.1 65.9 - - - 36.5 1095 -
playspu SPEQ_SYNTH=spu
SPEQ_DEBUG=1		 - - - 57 - whole run 37.5 65.9 - - - 26.5 465 -
fluidsynth ps3.309 (SPU synth v2) + libspeq 0.318 + Mesa ps3.299 2026-10-17 · 2026-10-17-fluidsynth-309
Tested: The second version of FluidSynth's voice processing on the SPUs (single-precision vector code, one round trip per write, two SPUs) against stock FluidSynth, on dsda-doom's music.
Result: It halves the underruns (1231 to 588 and 1331 to 709) and cuts the CPU from 44.5 to 31.8 s a minute. The user listened to both: "night and day, spu makes a huge difference".
What we saw
  • dsda-doom playing its demo at normal speed with FluidSynth music. Two pairs, stock then SPU, in the same session.
  • ALSA underruns: 1231 to 588 and 1331 to 709.
  • CPU: 44.5 to 31.8 s per minute. With no music at all: about 29 s and 18 underruns.
  • The user listened to both: "night and day, spu makes a huge difference". The only glitches left coincide with the game's own stutters.
  • The first version (double precision, one block per job) had only gone from 1335 to 1097 underruns.
playoff SPEQ_SYNTH=off - - - 54.0 Mesa ps3.299 whole run 39.4 65.4 - - - 46.4 1281.0 -
playspu SPEQ_SYNTH=spu
SPEQ_DEBUG=1		 - - - 54.5 Mesa ps3.299 whole run 47.7 65.4 - - - 32.3 648.5 -
fluidsynth voice DSP on the SPEs (libspeq 0.288; Mesa ps3.282) 2026-10-17 · 2026-10-17-fluidsynth-spu-dsp
Tested: A first version of FluidSynth's voice processing moved to the SPUs (libspeq 0.288), to see whether it frees the PPE and stops dsda-doom's music from chopping.
Result: The CPU cost of the music almost disappeared (49.3 s to 31.7 s), but the underruns only fell from 1335 to 1097, far from the 18 without music. The kernel computed in double precision, too slow per block; a second version followed.
What we saw
  • dsda-doom playing its demo at normal speed for 60 s with the GL renderer and FluidSynth music. One run each.
  • Stock FluidSynth: 49.3 s of CPU and 1335 underruns.
  • Voice processing on the SPUs: 31.7 s of CPU and 1097 underruns. HUD 53 and 54 fps.
  • The SPUs did the work: 20227 of 20295 blocks, 55 timeouts, no errors, mean wait 731 us (max 9.2 ms).
  • The CPU drops close to the 29 s of a run without music, but the underruns stay far above that run's 18. Cause not established.
  • Per the coordinator, the SPU code computed in double precision, too slow per block (not visible in the run folders).
  • Whether the music sounded right is not recorded. There is no run of the same build on the PPE. The FluidSynth build used is not in the versions file.
playoff SPEQ_SYNTH=off - - - 53 Mesa ps3.282 whole run 39.5 65.4 - - - 49.3 1335 -
playspu SPEQ_SYNTH=spu
SPEQ_DEBUG=1		 - - - 54 Mesa ps3.282 whole run 40.0 65.4 - - - 31.7 1097 -
Mesa ps3.262 runs with perf recording (audio profiling) 2026-10-17 · 2026-10-17-mesa-262-perf
Tested: Plain-named runs made while the audio profiling was going on: dsda-doom's music, OpenArena and Yamagi Quake II on Mesa ps3.262.
Result: Not valid for comparison: perf was recording during these runs, which explains the slow OpenArena and Yamagi numbers. They say nothing about a change in Mesa ps3.262.
What we saw
  • Perf was recording during these runs (said by the coordinator; the run folders do not show it). The numbers are not for comparison.
  • dsda-doom playing at normal speed, twice: 1276 and 1422 ALSA underruns, HUD 51 and 50 fps. Probably the runs behind the profile that put the FluidSynth library at 48.3% of the game's samples.
  • OpenArena: 39.7 fps with a 5.9 s longest frame, then 23.4 fps with a 15 s stall (the run ended with an error). The unprofiled suite run had 54.4.
  • Lowest free memory in the two OpenArena runs: 38 and 13 MB.
  • Yamagi Quake II: 55.2 fps (63.9 in the suite round).

not comparable runs with perf recording (audio profiling), slower than plain runs.
play
not comparable		 the recipe as it is - - - 50.5 Mesa ps3.262 whole run 19.6 65.4 - - - 51.1 1349.0 -
Mesa ps3.262 + ps3rsx 0.249 2026-10-17 · 2026-10-17-mesa-262
Tested: Mesa ps3.262 (patches 0019 to 0025: fewer words sent to the GPU per draw) across the suite, against ps3.246.
Result: Big gains in several games: OpenArena +23%, Yamagi +24%, X-Moto +21%, Extreme Tux Racer and dsda-doom +15%. Armagetron fell from 60 to 51 fps, which the next batches traced. Single runs; BananaBread's drop is a memory stall, not a driver number.
What we saw
  • The patches: no relocations, the texture cache invalidated only after texture changes, no duplicate vertex-format writes, batched vertex program constants. One run per game.
  • Against ps3.246: OpenArena with compressed textures 44.2 to 54.4 fps (+23%), Yamagi 51.4 to 63.9 (+24%), X-Moto 39 to 47 (+21%), Extreme Tux Racer 46 to 53 (+15%), dsda-doom software 33 to 38 with the demo now finishing (+15%), ClassiCube 47.6 to 50.1 (+5%).
  • Neverball 78.2 to 71.5 (noise), QuakeSpasm 70.5 to 66.3 (repeated in the next batch), Luanti 53 to 53.
  • Armagetron dropped from 60 to 51 (driver frame counter).
  • BananaBread reads 28 to 8 on the counter, but it was memory-stalled (13 MB free, killed at the cap): not a driver number, and the cause is uncertain.
  • The kernel's command validator rejected nothing.
  • Single runs.
base the recipe as it is - - - 38.0 Mesa ps3.262, ps3rsx 0.249 whole run 40.5 25.7 - - - 110.7 1768 -
Mesa ps3.246 + ps3rsx 0.249 2026-10-17 · 2026-10-17-mesa-246-ps3rsx-249
Tested: The first full suite round after the reboot into ps3rsx 0.249, one run per game, as a baseline.
Result: Every game ran with the right picture. The sound was right except in dsda-doom (MIDI music), BananaBread and OpenTTD. Single runs, so differences of a few fps are noise.
What we saw
  • One run per game. Frame rates by the game's own counter, or the driver's frame counter where marked:
  • Armagetron 60 (counter), ClassiCube 47.6, dsda-doom software 33 (counter, demo unfinished), Extreme Tux Racer 46 (counter), Luanti 53 (counter), Neverball 78.2.
  • OpenArena with compressed textures 44.2 (longest frame 2.1 s), QuakeSpasm 70.5, BananaBread with CPU skinning 28 (counter), X-Moto 39 (counter), Yamagi Quake II 51.4.
  • Pictures right. Sound right except dsda-doom (1161 underruns, MIDI music), BananaBread (176) and OpenTTD (1429, choppy).
  • OpenTTD used 55.5 s of CPU and has no frame rate (plain X11 path).
  • Single runs: differences of a few fps are within the run-to-run spread.
base the recipe as it is - - - 33 Mesa ps3.246, ps3rsx 0.249 whole run 52.5 25.7 - - - 65.0 1161 -
dsda-doom sound settings against the underruns (Mesa ps3.225) 2026-10-17 · 2026-10-17-dsda-doom-sound
Tested: Whether a sound setting (OPL music, 48 kHz mixing, a bigger buffer, a frame cap) can bring dsda-doom's underruns down with music on.
Result: None comes near the 18 underruns without music; the best, everything tuned together, still had 340. Either the music default changes or the synth moves to the SPEs; the decision was left to the user.
What we saw
  • One setting at a time, 60 s of play at normal speed, single runs.
  • Everything tuned (OPL music, 48 kHz, bigger buffer, 60 fps cap): 340 underruns, 46 s of CPU.
  • OPL music: 1312 underruns in the first run and 877 in the second (the table holds their mean). The second run crashed with a segmentation fault. The first used 54 s of CPU like plain play (53 s), the second 44 s, so the first may not have applied the OPL setting.
  • 35 fps cap: 1385 underruns. 48 kHz mixing: 1471.
  • Without music: 18 underruns (previous batch).
play48k the recipe as it is - - - 52 Mesa ps3.225 whole run 50.4 65.4 - - - 51.3 1471 -
playcap35 the recipe as it is - - - 34 Mesa ps3.225 whole run 54.1 65.4 - - - 47.8 1385 -
playopl the recipe as it is - - - 50.5 Mesa ps3.225 whole run 54.7 65.4 - - - 49.1 1094.5 -
tuned the recipe as it is - - - 50 Mesa ps3.225 whole run 47.7 65.4 - - - 46.0 340 -
dsda-doom +ps3.247 GL renderer and music on/off (Mesa ps3.225) 2026-10-17 · 2026-10-17-dsda-doom-gl-music
Tested: Whether fluidsynth's MIDI music causes dsda-doom's sound dropouts: the demo played at normal speed with and without music.
Result: Yes: the music costs about 24 s of CPU a minute (about 40% of a PPE thread) and causes the chopping. Without music the underruns fell from 1280 to 18 a minute.
What we saw
  • Our dsda-doom +ps3.247, Mesa ps3.225, ps3rsx 0.219, single runs.
  • GL renderer timedemo: 48.8 fps, 1549 underruns.
  • Demo at normal speed for 60 s with music: 52 fps on the driver's frame counter, 53 s of CPU, 1280 underruns a minute.
  • The same without music: 53 fps, 29 s of CPU, 18 underruns.
  • So fluidsynth's music costs about 24 s of CPU a minute (about 40% of a PPE thread) and causes the chopping.
  • Underruns counted from the game log.
gl the recipe as it is - - - 48.8 Mesa ps3.225 whole run 60.8 61.5 - - - 63.2 1549 -
play the recipe as it is - - - 52 Mesa ps3.225 whole run 43.0 65.4 - - - 53.4 1280 -
playnomusic the recipe as it is - - - 53 Mesa ps3.225 whole run 62.9 65.4 - - - 28.9 18 -
dsda-doom +ps3.231 colours fix (Mesa ps3.225) 2026-10-16 · 2026-10-16-dsda-doom-colours
Tested: Our dsda-doom package +ps3.231 with big-endian and nv30 fixes: are the colours right now, and how fast are the GL and software renderers?
Result: The colours are right, and the GL renderer runs at 1920x1080 at 48.2 fps. The sound still chops (1542 to 1888 underruns per run), caused by fluidsynth's MIDI music on the main CPU.
What we saw
  • Our dsda-doom 0.30.0 +ps3.231 (big-endian and nv30 fixes). Colours right.
  • GL renderer at 1920x1080: 48.2 fps, 64 s of CPU. It uses a luminance-alpha fallback, since the GPU lacks two-channel (RG) textures.
  • Software renderer at 960x540: 20 fps on the driver's frame counter, 112 s of CPU.
  • The sound still chops: 1542 to 1888 underruns per run, from fluidsynth's MIDI synthesis on the PPE.
  • Single runs.
base the recipe as it is - - - 20 Mesa ps3.225 whole run 43.3 25.7 - - - 111.5 1888 -
gl the recipe as it is - - - 48.2 Mesa ps3.225 whole run 61.3 61.5 - - - 63.6 1542 -
Group 1 dsda-doom software 960x540 and SDL variants (Mesa ps3.186) 2026-10-16 · 2026-10-16-dsda-doom-software
Tested: dsda-doom's software renderer at 960x540 with three ways of putting the picture on screen: SDL's OpenGL renderer, its GLES2 renderer and its software renderer.
Result: GLES2 was fastest (29.2 fps against 20.2), SDL's software path unusable (1 fps). Every variant had wrong colours and thousands of sound dropouts, from big-endian bugs; fixed in our dsda-doom package +ps3.231.
What we saw
  • Debian dsda-doom 0.30.0, Freedoom demo 1, one run per variant.
  • Software renderer scaled by SDL's OpenGL renderer: 20.2 fps (finished at 148 s), 185 s of CPU.
  • SDL's GLES2 renderer: 29.2 fps, 131 s of CPU.
  • SDL's software renderer: 1 fps, killed at 300 s.
  • The colours were wrong with every SDL renderer (rotated; the first run green-tinted): a big-endian bug in the game and SDL.
  • The sound underran thousands of times: 3210, 2272 and 6741 underruns in the three runs.
  • Fixed in our dsda-doom package (see the +ps3.231 batch).
base the recipe as it is - - - 20.2 Mesa ps3.186 whole run 54.1 17.8 - - - 185.4 3210 -
gles SDL_RENDER_DRIVER=opengles2 - - - 29.2 Mesa ps3.186 whole run 58.2 17.8 - - - 130.7 2272 -
sdlsw SDL_RENDER_DRIVER=software - - - 1 Mesa ps3.186 whole run 48.7 23.8 - - - - 6741 -
Group 1 dsda-doom first smoke at 1920x1080 software (Mesa ps3.186) 2026-10-16 · 2026-10-16-dsda-doom-smoke
Tested: The first dsda-doom run: Debian's build with the software renderer at the full 1920x1080.
Result: Far too slow: 5 fps, the demo didn't finish within 180 s, and the sound underran 3618 times. The recipe was changed to draw at 960x540 and let SDL scale the picture up.
What we saw
  • Debian dsda-doom 0.30.0, software renderer at 1920x1080, single run, no fps line from the game.
  • 5 fps median on the driver's frame counter (10th percentile 3, minimum 2).
  • The demo did not finish within the 180 s cap (183 s wall time).
  • 3618 ALSA underruns (sound dropouts), counted from the game log.
  • Free memory fell to 38 MB.
base the recipe as it is - - - 5 Mesa ps3.186 whole run 38.1 - - - - - 3618 -