Nova Drift Racing on Switch: Audio Testing Beyond 'Can I Hear It?'
Iron Kite is porting Nova Drift Racing to Switch. Audio is authored in an FMOD project with 1,180 events across 14 banks; banks are rebuilt on every CI build. Three problems are open. (a) After a race restart, the engine loop goes silent, but only when the console is docked and the TV output is set to surround; handheld and stereo TV output are fine. (b) Footstep events are missing on the 'Salt Flats' level only, on all outputs. (c) Cinematics must hit a loudness target of -24 LKFS ±2 for submission, and the current mix has never been measured. The audio lead says the FMOD project 'is the source of truth' and that the game build should match it. You have one audio engineer, one Switch devkit, and a TV with a soundbar in the office; no treated room.
1. Design the audio test approach for this port. What do you check at event, bank and output level, and how do you narrow bug (a)?
Read the worked answer
Three layers, each with a different oracle.
Event level: every gameplay event fires when expected and maps to the right FMOD event path. Check event counts against the design sheet, not against what the audio lead remembers. Missing footsteps on one level is an event-level or bank-level fault, not a mix issue - a whole category absent in one scene points to a level-specific bank or a parameter that is out of range on Salt Flats.
Bank level: a build diff that compares the CI-built banks against the FMOD source project - event count, bank contents, sample rate, and any events present in source but absent from the shipped bank. 'The project is the source of truth' is exactly the assumption to test, because CI rebuilds are where events silently drop out.
Output level: channel routing, downmix and loudness per output configuration.
For (a), bisect the configuration, not the code: docked + surround fails, docked + stereo passes, handheld passes. That isolates the surround downmix or the channel mapping for the engine loop. Then check whether the event is a 5.1 asset routed to a bus that is muted on restart, and whether the restart path re-initialises the bus while leaving the event instance alive. Reproduce with a fixed sequence (start race -> restart -> restart) and log FMOD bus states at each step.
2. Write the core content of a bug report for the missing footsteps that a developer can act on without asking you questions.
Read the worked answer
Title: Salt Flats - all footstep events silent on all outputs; other levels unaffected.
Environment: dev build 0.9.3, Switch devkit serial X, docked and handheld, stereo and surround, all characters tested.
Steps: load Salt Flats, walk on sand, metal grating and boardwalk surfaces for 60 seconds each, then restart the level and repeat.
Expected: surface-specific footstep one-shots per step, as on the other four levels. Actual: no footstep audio on any surface, any character, any output; no errors in the log. Music, engine and collision audio are present.
Evidence: video with a simultaneous FMOD event log showing zero footstep event calls on Salt Flats versus the expected calls on Dune Pass; bank build hash for build 0.9.3; a note that the FMOD source project contains the footstep events and the CI bank diff shows the Salt Flats bank is 40 KB smaller than the previous build.
Scope: does not reproduce in the editor, only in packaged builds - which, combined with the bank size delta, points at the build pipeline rather than the level data. That single sentence is what saves the developer a day.
3. How would you verify the -24 LKFS ±2 cinematic target without a treated room, and what would you refuse to certify?
Read the worked answer
You can verify program loudness without a treated room; what a room affects is accurate monitoring, not integrated loudness measurement. Integrated loudness is a measurement of the signal, so I would capture the audio digitally rather than through a microphone: take the Switch's audio output into an interface, or better, capture the rendered mix from the engine, and measure integrated loudness with a meter implementing ITU-R BS.1770-style integrated loudness. That gives a defensible number for the submission target independent of the office acoustics.
Procedure: measure the full cinematic from start to end, not a 30-second excerpt, because integrated loudness averages the whole programme. Repeat per output configuration (stereo, surround), since the downmix can shift the value. Record the meter settings and the build hash with each measurement.
I would refuse to certify: perceived mix balance, dialogue intelligibility, and dynamic-range judgements, because the untuned soundbar and room modes will mislead. Those go to a proper listening session or to the audio lead's reference headphones. I would also flag any measurement taken from a lossy capture, and any cinematic re-rendered after the measurement, as invalid.