Crylia/lgtv_audio_cap
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity

Add a brightness-only sink: keep the grabber's colour, pulse with sound

Browse Source 
Every existing HyperHDR route replaces whatever else is on the LEDs:
routes 1/2 hand HyperHDR's own audio effect a device to read, route 3
sends a synthetic spectrum image, and both take over via HyperHDR's
priority system. For a setup that already has a real colour source
(a screen grabber, a USB capture card) feeding an ambilight-style LED
run, none of that is what's wanted -- the colour should stay put and
only brightness should react.

Read HyperHDR's own source (sources/api/JSONRPC_schema/schema-adjustment.json)
rather than guess: "adjustment" is a post-processing command with a
scaleOutput parameter (0-2.0) that applies regardless of which
priority is currently active. Confirmed the wire format too --
sources/jsonserver/JsonClientConnection.cpp frames it as plain
newline-delimited JSON over TCP (default port 19444), nothing like the
length-prefixed Flatbuffers protocol the visualiser sink speaks, and
with no handshake or registration needed before the first write.

sink_hyperhdr_adjust.c sends only that: no image, no priority, so it
never competes with an existing grabber. Non-blocking connect with the
same poll()+SO_ERROR pattern net/hyperion.c already uses, reconnects
every 5s, rate-limited to 20 Hz (a HyperHDR command every audio block
would be pointless flooding), and resets scaleOutput to 1.0 on close
rather than leaving the LEDs stuck at whatever it last sent. Cross-
compiles clean under -Wall -Wextra on the real webOS toolchain.

Wired through the same path every other sink follows: registered in
sink.c/sink.h, defaults in config.c, fields in frontend/js/app.js
(SINK_FIELDS/SINK_HELP), mock.js and ui_smoke.js updated for the new
sink card. Bumped to 1.0.3.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Rene Kievits
2026-08-26 14:36:31 +02:00
co-authored by Claude Opus 5
parent f0f68a1aa7
commit aae5a33283
15 changed files with 402 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/hyperhdr.md
+45 -8
View File
@@ -166,17 +166,54 @@ lights go fully dark between beats, which looks dramatic and slightly broken.
---
## 4. Keep your grabber's colour, only pulse the brightness
For an ambilight-style setup that already has a real colour source — a
screen grabber, a USB capture card, an HDMI splitter — routes 1–3 all have
the same problem: they compete for HyperHDR's priority and *replace* that
colour with something audio-derived. This route doesn't touch colour at all.
HyperHDR has a JSON-RPC `adjustment` command that scales output brightness as
a post-processing step, applied on top of whatever priority is currently
active. This sink sends nothing but that: no image, no priority
registration, so the grabber keeps deciding hue and this only turns the
result up and down with the sound.
```
TV ──RTP or local──► audiocap-service ──JSON-RPC "adjustment"──► HyperHDR
(still showing
the grabber's colour)
```
*Outputs → HyperHDR brightness (JSON-RPC)*
| Setting | Value |
| --- | --- |
| HyperHDR address | the HyperHDR machine's IP |
| JSON-RPC port | 19444 (HyperHDR's classic control port — not 8090, the web UI; not 19400, Flatbuffers) |
| Follows | Average level (steadier) or Peak level (punchier) |
| Minimum brightness | `1.0` = HyperHDR's normal brightness; lower dims during quiet parts |
| Maximum brightness | up to `2.0`; boosts past normal on loud peaks |
Needs a working capture source the same as every other route — see the top
of this document for picking one. On close, the sink resets `scaleOutput` to
`1.0` rather than leaving the LEDs stuck at whatever it last sent.
---
## Which one to use
| | Route 1 | Route 2 | Route 3 |
| --- | --- | --- | --- |
| Host software | receiver + loopback | none | none |
| HyperHDR effects | all of them | all of them | none, the TV renders |
| Latency | ~100 ms | ~100 ms, less stable | ~40 ms |
| Robustness | good | depends on your PulseAudio | good |
| Setup time | 10 minutes | 2 minutes if it works | 1 minute |
| | Route 1 | Route 2 | Route 3 | Route 4 |
| --- | --- | --- | --- | --- |
| Host software | receiver + loopback | none | none | none |
| HyperHDR effects | all of them | all of them | none, the TV renders | your existing grabber, untouched |
| Colour source | HyperHDR's built-in audio effect | HyperHDR's built-in audio effect | this app's synthetic spectrum | your grabber — this only adjusts brightness |
| Latency | ~100 ms | ~100 ms, less stable | ~40 ms | ~50 ms |
| Robustness | good | depends on your PulseAudio | good | good |
| Setup time | 10 minutes | 2 minutes if it works | 1 minute | 1 minute |
Route 1 unless you have a reason.
Route 1 for HyperHDR's own audio effects. Route 4 if you already have a
grabber and just want it to breathe with the sound instead of being replaced.
---