DAX applies Virtual Bass Enhancement on HDA devices; our converter doesn't

[antoinecellerier]

Setup

Bass-burst captures on the X1 Yoga (DEV_0287_SUBSYS_17AA22E6, profile=Dynamic) — sustained sine tones at 50/80/120/180 Hz — surfaced clear evidence that DAX3 applies Virtual Bass Enhancement (psychoacoustic harmonic synthesis) that our converter doesn't reproduce.

Evidence

Spectrum of the captured 50 Hz tone region (loud, peak −5 dBFS), Hann-windowed:

freq        magnitude
 50.0 Hz   −36.3 dBFS    ← fundamental
150.0 Hz   −37.6 dBFS    ← 3rd harmonic (1.3 dB below fundamental)
250.0 Hz   −38.1 dBFS    ← 5th harmonic
300.0 Hz   −49.4 dBFS    ← 6th
200.0 Hz   −50.6 dBFS    ← 4th
350.0 Hz   −54.3 dBFS    ← 7th

For comparison, the 180 Hz capture in the same battery has all non-fundamental peaks ≥35 dB below the fundamental — clean sine, crest factor 4.4 dB. The 50 Hz region's crest factor is 22.9 dB.

The pattern is the textbook signature of missing-fundamental synthesis: dominant odd harmonics at near-fundamental amplitude, fundamental preserved (not boosted), even harmonics suppressed. The auditory system reconstructs a 50 Hz percept from the harmonic complex — the standard psychoacoustic-bass mechanism (SRS TruBass, Waves MaxxBass, Dolby's own VBE).

What our converter does

make_preset() in dolby_to_easyeffects.py enables Calf BassEnhancer (bass_enhancer#0) only when is_soundwire=True. HDA devices like the X1 Yoga get no VBE in the generated chain. Our 50 Hz capture in the same battery is just an attenuated 50 Hz fundamental at −50.5 dBFS with no significant harmonic content — clean sine, crest 3 dB.

So the X1 Yoga preset is missing the harmonic-generation stage entirely.

What the XML says

The X1 Yoga XML has all VBE-adjacent fields populated:

<bass-enhancer-enable value="0"/>
<bass-enhancer-cutoff-frequency value="200"/>
<virtual-bass-mode value="0"/>
<virtual-bass-mix-freqs value="94,469"/>
<virtual-bass-subgains value="-32,-144,-192"/>
<virtual-bass-src-freqs value="35,160"/>

The enable=0 / mode=0 flags read as "off", but every other parameter is non-default and looks configured. Two readings:

1. mode=0 is honestly off, and DAX has a baseline VBE that always runs (not in the schema). The supporting parameters are dead schema slots.
2. mode=0 is a specific mode label (auto / default), and the supporting parameters configure it.

The captures don't disambiguate, but reading (2) feels more consistent — DAX is clearly doing harmonic synthesis, the schema fields are populated, and "configured but ignored" is a strange shape for shipped tunings.

The converter currently treats the entire bass-enhancer-* / virtual-bass-* schema family as skipped (per Finding 5 in docs/design-notes.md), so neither reading is acted on today.

Implications

• The X1 Yoga (and presumably other HDA devices) ships without psychoacoustic bass synthesis on Linux despite the XML carrying configuration for it.
• This is part of the EE-vs-DAX bass gap on real content (separate from the steady-state chain-attenuation gap tracked in EQ frequency-response gap between our converter output and DAX3 (>5 kHz; ~28 dB at 19.7 kHz) #12 — that's LTI; this is nonlinear).
• Listening test would pick this up before measurement does — bass-heavy content on the EE chain "feels thinner" than on DAX, even when the spectrum-flat region matches.

Open questions

1. Is reading (1) or (2) correct? Needs a corpus check: are there XMLs where mode != 0, and if so, do any of the supporting parameters change in a way that would help us infer the mapping?
2. If reading (2) is right, what's the mapping from virtual-bass-mix-freqs / subgains / src-freqs to Calf BassEnhancer parameters (amount, scope, harmonics, blend)? The Calf plugin's parameter space is much smaller than DAX's; the mapping may not be one-to-one.
3. A second-device DAX capture comparing two devices with different virtual-bass-* parameters would help validate any mapping. Same risk profile as the stress investigation in the Impulse Responses aren't doing anything #11 follow-up — blind re-interpretation without external validation isn't safe to ship as default.

Possible next steps

• Cheap: corpus sweep for virtual-bass-* value distribution. Are these values constant across the corpus (like regulator-overdrive/relaxation) or do they vary?
• Medium: enable Calf BassEnhancer for HDA devices behind an opt-in flag, with the cutoff derived from the chain HP and amount mapped from virtual-bass-overall-gain (or similar). Listening test on bass-heavy content. Risk: Calf BassEnhancer's harmonic profile likely doesn't match DAX's exactly, so this might "add some VBE" without "matching DAX's VBE".
• Speculative: capture DAX response on multiple devices with varying virtual-bass-* values to actually pin down the schema interpretation.

Tracked separately from the EQ-curve gap in #12 — that's a frequency-domain LTI question; this is a missing nonlinear processing stage.

🤖 Generated with Claude Code

[antoinecellerier]

Closed both open questions from the issue body and an additional companion-files question, all in the same direction.

Q1 (corpus sweep): do virtual-bass-* fields vary?

Across 2,470 XMLs that contain VBE fields, every supporting field is frozen identical:

field	unique values across 2,470 XMLs
virtual-bass-mode	0 only
bass-enhancer-enable	0 only
virtual-bass-mix-freqs	94,469 only
virtual-bass-src-freqs	35,160 only
virtual-bass-subgains	-32,-144,-192 only
virtual-bass-overall-gain	0 only
virtual-bass-slope-gain	0 only

If reading 2 of the issue body were correct (mode=0 is a label, supporting fields configure the synthesis), these would vary across hundreds of distinct speaker designs the way mb_comp thresholds and IEQ curves do. They don't. Reading 1 is favored, but either reading leads to the same actionable conclusion: the schema cannot drive a per-device VBE mapping.

A *-mode survey across the schema also showed that 0 is not universally "off" (e.g. height-filter-mode is 0/1 in the corpus), so the reading-1-vs-2 question isn't fully closed by schema-pattern alone. The strongest precedent for a feature with both a separate *-enable and tuning fields is dialog-enhancer-enable=0 with dialog-enhancer-amount=7 — tuning fields persist as dead values when the gate is off — which is consistent with reading 1.

Q2 (companion files): is there a per-device VBE source we're not reading?

Each DAX3 driver package ships:

• The main per-device tuning XML (we use this; VBE fields frozen)
• _settings.xml — UI-only state (AutoProfile mappings, GUI flags)
• operator_settings_*.json — Dolby Access vendor config (mirroring, auto-profile behavior)
• .inf / .cat — driver-install metadata + signature catalog
• _amic.xml / _dmic.xml — mic-side tunings, already filtered

None carry VBE tuning. The DAX3 binaries themselves could carry an internal lookup table keyed on PCI subsystem ID, but reading that requires reverse-engineering the DLL and is out of scope. Within the text-readable per-device data we ship against, no VBE source exists.

Documentation landed

Findings written up as design-notes Finding 8 ("DAX runs psychoacoustic VBE; the schema can't drive a per-device mapping"), including the spectrum evidence, corpus sweep, and companion-file audit.

Empirical follow-up: Calf BassEnhancer hits an architectural ceiling

A temporary --enable-vbe investigation flag was added to extend Calf BassEnhancer emission to HDA devices, with make_bass_enhancer extended to derive floor / scope from virtual-bass-src-freqs (field is in tuning-cp, corpus-frozen at 35,160). Bass-burst captures (X1 Yoga, dynamic/balanced) compared the unflagged chain, the flagged chain, and DAX:

tone	EE off Δ3	EE+VBE Δ3 (XML-derived bounds)	DAX Δ3
50 Hz	−81 dB	−8 dB	−1 dB
80 Hz	−102	−29	−28 ← matches DAX
120 Hz	−102	−42	−59
180 Hz	−112	−18 ← regression	−74 (clean)

A 6-variant parameter sweep (harmonics 3/5/10, blend -10/0/+10, amount 6/12) confirmed the regression is structural: every variant trades 50 Hz benefit linearly for 180 Hz regression. Calf BassEnhancer's internal source-band filter has soft (~12 dB/oct) rolloff at scope, so 180 Hz with scope=160 is only ~4 dB attenuated as input — strong 3rd-harmonic at 540 Hz still gets generated. Calf's distortion model also leaks 2nd harmonics ~10 dB stronger than DAX's profile.

A PoC with Calf Saturator + brick-wall pre/post filters (hp_pre=35, lp_pre=160, hp_post=180, lp_post=800, drive=4) lowers the 180 Hz ceiling by ~13 dB versus BassEnhancer (Δ3 −31 vs −18) but still leaks ~40 dB above DAX's clean profile. EE 8.x has no saturator plugin slot so this would only ship for ee_to_pipewire.py users.

The investigation flag has been reverted. Both findings are in docs/design-notes.md Finding 8 as the durable record.

Status

Keeping #14 open as the canonical reference until the measurement verdict is in. The "second-device DAX captures" item from the issue's "Possible next steps" remains open as the only way to test whether DAX's behavior varies even when the XML doesn't.

🤖 Generated with Claude Code

[antoinecellerier]

Follow-up to the prior comment. Two more architectures tested; one of them breaks the single-plugin 180 Hz ceiling.

Calf MultibandEnhancer — does not escape the ceiling. A 24-variant sweep across crossovers, per-band drive (0..10), blend (−10..+10), and base parameters found that the best variant produces a DAX-shaped tapered Δ3 (weakening with frequency) but caps at 50 Hz Δ3 ≈ −20 dB versus DAX's −1 dB. The plugin's harmonic generator is a memoryless wave-shaper with a fixed intensity ceiling; no parameter combination crosses it. It is also even-dominated at 50 Hz where DAX is strongly odd-dominated. Cannot substitute for the BassEnhancer / Saturator path.

Cascading LSP filter_stereo + Calf Saturator — escapes the ceiling. Two LSP filter stages in front of Calf Saturator with BWC-mode brick-wall slopes (x16 ≈192 dB/oct on input edges, x8 ≈96 dB/oct on output edges), Saturator's internal pre/post filters disabled to avoid double-filtering:

HP@35 (BWC x16) → LP@160 (BWC x16)
  → Saturator (drive=4, mix=1.0, blend=0, internal pre/post=off)
  → HP@180 (BWC x8) → LP@800 (BWC x8)

Final wet-only Δ3 vs DAX:

tone	calf_v2 (BE) Δ3	sat_v1 (single Saturator) Δ3	LSP+Sat chain Δ3	DAX Δ3
50 Hz odd/even ratio	+16	+11	+56	+26
80 Hz odd/even ratio	+8	+6	+16	+48
180 Hz	−18 (regression)	−31	−56	−74 (clean)

A 38 dB improvement on the load-bearing 180 Hz regression, landing 17 dB above DAX's clean profile rather than the 56 dB above we got with single-plugin Calf BassEnhancer. The 50 Hz / 80 Hz odd-dominance ratios (+56 / +16 dB) confirm Calf Saturator produces near-symmetric saturation when fed a clean band-passed input — the even-harmonic leakage in earlier single-plugin tests was an artefact of out-of-band content reaching the saturator, not a property of the saturator itself.

Caveat — ceiling-break is for harmonic structure only. The plot above is the wet-only output of the chain (mix=1.0, post-HP at 180 Hz kills the band-passed fundamental). In a real deployment the wet path would sum with a parallel dry chain that carries the fundamental, but our dry chain attenuates 50 Hz to ~−66 dBFS while the wet residual sits at ~−54 dBFS, so the mixed 50 Hz fundamental lands ~9 dB below DAX's captured −45 dBFS. That's a separate gap (the steady-state bass-attenuation gap from Findings 4/7 — DAX's regulator/leveler boosts quiet sustained low tones), not one the harmonic synthesizer addresses. Calf BassEnhancer in earlier tests appeared to close part of it because its mix structure passes boosted dry-band signal through — but that conflated the two gaps at the cost of the 180 Hz regression. The Saturator-based path keeps the gaps separated, which is honest but means closing the harmonic gap doesn't close the magnitude gap. The mixed parallel-dry-plus-wet capture is the next concrete measurement before any ee_to_pipewire.py change ships.

Implication. A faithful-ish VBE for HDA is possible — but only via the PipeWire filter-chain path (ee_to_pipewire.py). EE 8.x has no plugin slot for cascaded LV2 filters in series. Splitting VBE behaviour across the two output paths (EE-mode users get nothing; PW-mode users get an approximation that tracks DAX's selectivity to within ~17 dB at 180 Hz with strongly odd-dominated lower-tone synthesis) becomes a maintenance-cost decision rather than a measurement one.

Status. Documentation updated in docs/design-notes.md Finding 8. No code shipping from this round. The natural follow-up is extending ee_to_pipewire.py to inject this LSP-cascade-plus-Saturator chain when the XML has virtual-bass-mode=0 and is_soundwire=False, gated on a listening test confirming the captured improvement is audible. Issue #14 stays open as the reference for the gap.

🤖 Generated with Claude Code