app

Adom TTS: Text to Speech

Public Made by Adom

by adom

Adom's shared voice service. Reads your AI's answers back to you while you drive, and renders perfectly-timed voiceover tracks for your demo videos, so you never record your own voice.

ttsvoiceaudiodemoaccessibilitycliopen-sourcemit
Overview Files Skills Discover Packages Releases Dependencies Issues1 Breadcrumbs Pull Requests Activity
Closed general

Hands-free on Hydrogen Desktop: the hydrogen surface needs a live cloud editor session, which a Desktop user rarely has; add a desktop surface through Hydrogen Desktop's own window

John Lauer · 1mo ago ·closed by John Lauer

Measured 2026-09-09 (adom-tts 1.9.50, Hydrogen Desktop 1.0.307 on AdomLapper). John asked for a read-back while at his laptop running Hydrogen Desktop. The default surface (hydrogen webview) opens the player tab with adom-cli hydrogen webview open-or-refresh against the CLOUD editor session; adom-cli hydrogen probe said browser_connected:false (his cloud editor tab in Edge had gone stale after a sleep), so every attempt logged open_surface_failed 409 "No browser session is connected" and the clip ended surface-unavailable. Six times. The skill's advice (reopen, re-send without --surface pup) cannot help when there is no cloud session at all.

What did work from the container: Hydrogen Desktop's control API on the laptop, reached through Adom Bridge: POST /hbw/open {url: } opened the player in HD's standalone WebView2 window. The page connected, but the clip sat at pause_hold 0 s: WebView2 blocks audio autoplay without a user gesture, and adom-tts control play cannot supply one. (Hydrogen will set --autoplay-policy=no-user-gesture-required for its WebView2 so this window autoplays; that is Hydrogen's half.)

Ask: a third surface, desktop (or make hydrogen fall through to it when probe says no browser session): open the player page on the user's Hydrogen Desktop via ab -> hd_api POST /hbw/open (or a Hydrogen webview tab once HD exposes one), target chosen from ADOM_BRIDGE_TARGET or the single connected ab, and report which surface actually took the clip. A Desktop user with no cloud editor open is the common case, and today hands-free silently fails for them.

1 Reply

John Lauer · 1mo ago

Shipped in adom-tts 1.9.52.

What changed:

  • A third surface, desktop: the player page opens in Hydrogen Desktop's own browser window on your box, through Adom Bridge (hd_api POST /hbw/open). Target is ADOM_BRIDGE_TARGET, then the persisted env snapshot, then the single connected bridge; with several boxes and no pin it refuses and names the fix instead of guessing a screen. Use it with --surface desktop or adom-tts settings set surface desktop (also a Desktop button in the Settings modal).
  • Automatic fall-through: when the hydrogen surface fails because there is no browser session (the open call says so, or adom-cli hydrogen probe reports browser_connected:false), the drainer opens the desktop window instead, once, and logs surface_fallthrough {from: hydrogen, to: desktop}. Transient failures do not switch surfaces.
  • The surface that actually took the clip is recorded: the portfile carries it, every clip_end event names it, adom-tts settings prints "live now", the status pill shows it, and the Settings modal says "desktop (fell through from webview)".
  • Harness T13 covers the whole path with a fake adom-cli (no session) and a fake adom-bridge (records the hd_api call): 28 of 28 pass.

Not in my hands: WebView2 autoplay. Until Hydrogen sets its autoplay policy for the hbw window, the first clip there waits for a tap on play (the page pulses the button and says "tap play"). Once Hydrogen ships that, nothing on this side needs to change.

Verified on an isolated rig with the fakes; the first live run on AdomLapper is yours, since it opens a window on your desktop: adom-tts say "desktop surface test" --out /tmp/d.mp3 --thread test --desc "desktop surface" --play --confirm --surface desktop.

Log in to reply.