ZacharyZhang-NY/omarchycn
2
2
Fork 0
Code Issues Pull Requests 2 Actions Packages Projects Releases 3 Wiki Activity

Cover the XPS 16 with the XPS 14 speaker tuning

Browse Source 
Reported to suit the XPS 16 as well, so the tuning now matches both machines and
the directory is named for the pair rather than the one model.

Gating moves from the DMI product name to the product SKU, which is what Dell keys
the Cirrus speaker firmware on -- 10280db9 for the XPS 14, 10280dba for the XPS 16
-- so it identifies the speaker hardware itself instead of a marketing name. SKUs
are compared as whole values, not substrings, so this cannot widen to the rest of
the XPS line the way a short product-name match would: product_family on these
machines is "Dell Laptops".

match_sku and match_dmi are now lists, letting one tuning name every model it
covers. A plain string still works as a single entry.

The measurements in tuning.conf were taken on the XPS 14 (0DB9). The XPS 16 is
covered on report rather than measurement, and tuning.conf and the graph both say
so, because the profile's bass lift and high-pass were fitted against one
machine's excursion and distortion limits.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
David Heinemeier Hansson
2026-07-24 18:32:31 -07:00
co-authored by Claude Opus 5
parent aa9f0c54c5
commit a466dcc04f
4 changed files with 70 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/AUDIO-TUNING.md
+21 -6
View File
@@ -43,14 +43,29 @@ and the sink-listing scripts rather than for daily use.
## Adding a tuning
Add a directory with a `tuning.conf` and a `filter-chain.conf`. No new command is
needed: matching is data. A tuning declares `match_dmi` (checked against the DMI
product name and family) and `sink_pattern`, and needing both is specific enough
for most hardware. If yours needs a sharper test, set `match_command` to any
predicate instead — an `omarchy-hw-*` script, for example. `sink_pattern` is
required either way, since the graph's target sink is substituted from it.
needed: matching is data. A tuning declares how to recognise its hardware, plus the
`sink_pattern` its graph targets:
| Key | Matches on | Notes |
|---|---|---|
| `match_sku` | DMI product SKU, whole value | Most precise. Vendors key speaker firmware on it, so it identifies the hardware rather than a marketing name |
| `match_dmi` | DMI product name or family, substring | Convenient, but a short string widens fast — `product_family` here is `Dell Laptops` |
| `match_command` | Any predicate you name | For hardware needing a sharper test than either |
`match_sku` and `match_dmi` are lists, so one tuning can cover several models it has
been validated on:
```bash
match_sku=("0DB9" "0DBA") # XPS 14 and XPS 16
```
`sink_pattern` is required whichever method you use, since the graph's target sink
is substituted from it.
Gate narrowly and widen as models are validated; a tuning aimed at the wrong
drivers can sound worse than none and can stress them.
drivers can sound worse than none and can stress them. When a tuning covers a model
it was not measured on, say so in `tuning.conf` — the provenance fields are there to
keep that distinction visible rather than implied.
Two hard requirements: