Skip to content

Stage 8d: C API validation layer, device functions, sample_binaural - #47

Merged
razedproduction merged 1 commit into
masterfrom
stage-8d-capi-validation
Nov 10, 2026
Merged

razedproduction merged 1 commit into
masterfrom
stage-8d-capi-validation

Conversation

@razedproduction

Copy link
Copy Markdown
Owner

What

Stage 8d of the porting plan: the C API's validation layer and device functions, and an unchanged upstream program built against the port's phonon library.

  • Validation layer (crates/phonon-capi/src/validation.rs, wired into every module): with IPL_CONTEXTFLAGS_VALIDATION (callers of API 4.5+), each ipl* function checks its arguments and results as api_validation_layer.cpp does and logs the same warnings to the context's log callback: method name (__func__), type, the expression as the macro stringizes it, and the value as MSVC's std::to_string / %p print it. Expression strings are built with concat!, so validation allocates nothing unless it logs.
  • Devices (devices.rs): Embree, OpenCL, Radeon Rays and TrueAudio Next functions fail, as in upstream built without those libraries; retain gives null, a device list has no devices.
  • sample_binaural: the plan named upstream's src/itest, but it includes internal C++ headers, links the core object library and needs GLFW/ImGui/PortAudio, so it cannot build against phonon.h. Upstream's core/src/samples/sample_binaural.cpp (only phonon.h) is built unchanged against both upstream (sample_binaural_upstream) and the port's phonon.dll (sample_binaural_port, with GOLDEN_PORT_PHONON_DIR); tools/golden/run_sample.py runs either.

Verification

  • capi_validation goldens: 8 sections of log messages from upstream with hand-picked invalid values (NaN kinds, infinities, %f edge cases, bad enums/flags/bools, null pointers, mismatched shapes, bad probe indices, post-call checks). Match byte for byte; the same calls without validation log nothing. Device statuses EXACT.
  • capi_sample: the port-built sample's output and the same calls through the crate (on every CI platform) are within 2.9e-7 × peak of upstream's (FFT, R1). The port-built check is #[ignore] (needs the reference build; steps in tools/golden/README.md).
  • fmt, clippy (both), cargo test --all pass locally on Windows.

For reviewers

  • Deviations (DEVIATIONS.md): per-context log callback instead of upstream's global log; validated device factories fail instead of returning empty devices; checks that would crash upstream are skipped; context-settings warnings go to the new context's callback; only validation warnings are logged.
  • Upstream quirks kept are documented as R34 (e.g. the deviation model's callback is checked against IPL_AIRABSORPTIONTYPE_CALLBACK).
  • The plan's 8d row is reworded for the itest → sample_binaural substitution.

🤖 Generated with Claude Code

- Validation layer (IPL_CONTEXTFLAGS_VALIDATION, callers of 4.5+): every ipl*
  function checks its arguments and results as upstream's
  api_validation_layer.cpp does and logs the same warnings to its context's log
  callback (method name, type, stringized expression, value formatted as
  MSVC's %f/%p). Checks that would crash upstream are skipped.
- Embree, OpenCL, Radeon Rays and TrueAudio Next device functions: creation
  fails, retain gives null, a device list has no devices.
- Upstream's src/itest cannot build against phonon.h (internal headers, GLFW,
  ImGui, PortAudio); upstream's sample_binaural, written against phonon.h
  alone, builds unchanged against the port's phonon.dll instead.
- Goldens: capi_validation (8 sections of log messages, device statuses),
  capi_sample (input and upstream output). Messages match byte for byte;
  sample audio within 2.9e-7 x peak (FFT, R1), also for the port-built sample.
- Plan: 8d row, name map, R34; DEVIATIONS: validation and device rows.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@razedproduction
razedproduction merged commit 6677ffb into master Nov 10, 2026
3 checks passed
@razedproduction
razedproduction deleted the stage-8d-capi-validation branch November 10, 2026 09:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant