upstream-archive/VoiceStudio
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix(appimage): let the host GStreamer win, and stop sharing its registry (#1333) (#1354)

Browse Source 
* fix(appimage): let the host GStreamer win, and stop sharing its registry (#1333)

Recording from the AppImage failed with "No microphone found" on a Debian
13 host whose audio stack the reporter verified healthy (pactl, wpctl,
gst-launch with both pulsesrc and pipewiresrc), while the same build`s raw
binary recorded fine. GST_DEBUG=2 named it:

  WARN GST_REGISTRY gst_registry_binary_check_magic:
    Binary registry magic version is different : 1.23.90 != 1.3.0
  GStreamer element appsink not found. Please install it.

linuxdeploy bundles libgstreamer-1.0 because WebKit links it, but not the
plugins: those are dlopen`d, so nothing static can see them to copy. The
bundled core falls back to the host plugin directory, whose plugins were
built against the host core, the version check rejects them, and the scan
yields nothing. appsink is one of the casualties and it is the element
WebKit hands a capture stream to, so getUserMedia() rejects NotFoundError.

Same class as #1258 (frozen bundled library against a host that moved on)
in a different library, which is why OMNIVOICE_PREFER_SYSTEM_WEBKIT=1 did
nothing for the reporter. Since we ship no plugins, the host core is the
only one that can agree with the plugins that will load — so prefer it,
with OMNIVOICE_PREFER_SYSTEM_GSTREAMER=0 as the escape hatch.

Also isolate the registry cache. GStreamer keys ~/.cache/gstreamer-1.0/
registry.<arch>.bin by architecture alone, so two cores of different
versions clobber each other`s file: that makes the failure depend on which
app ran last, and the AppImage corrupts the cache for every other
GStreamer app on the machine. Both directions go away with a private path.

AppRun.test.sh covers host-present, host-absent and opt-out; all three
fail against the previous AppRun.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* test(appimage): cover the ldconfig discovery path; docs fixes

CodeRabbit, all three valid:

- every GStreamer case forced ldconfig to fail, so the runtime-only-host
  fallback (no -dev package, hence no .pc file) was never exercised. The
  cases now select their discovery path, and the new ldconfig one fails if
  that branch is removed.
- MD040: the GST_DEBUG fence had no language tag.
- the registry cache path follows XDG_CACHE_HOME when set; ~/.cache is only
  the default. Documented, along with WHY the shared file is a problem.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(appimage): compose LD_LIBRARY_PATH once; host WebKit stays first

CI caught a real regression, not a flaky test. The GStreamer block prepended
its own directory, which put it AHEAD of the host WebKit dir — and "host
WebKit first" is the invariant #1258 turns on. On a host where the two
libraries live in different directories that silently changes which WebKit
resolves.

It only showed on Linux because the WebKit ldpath cases do not stub away a
real host GStreamer, so the runner had one to find and macOS did not.
Reproduced locally with an ldconfig shim, and confirmed the ordering is what
fixes it: with the old order the suite is 19/2, with this one 21/0.

Both decisions now compose one path in one place — host WebKit, host
GStreamer, bundle, inherited — so neither preference is weakened and the
ordering is stated where it is applied rather than implied by two
independent prepends. Same directory for both (the common case) is not
listed twice.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(appimage): preload the host GStreamer instead of hoisting its libdir

greptile P1, valid. The host GStreamer lives in a general system library
directory (/usr/lib/x86_64-linux-gnu on Debian), so putting that directory
ahead of ${HERE}/usr/lib replaced EVERY other bundled library with the
host copy — loader symbol errors, startup crashes, or a blank window on a
distro we never built against. One library needs to come from the host and
the mechanism has to be that narrow.

LD_PRELOAD names exactly that library and leaves the search path alone, so
the WebKit ordering from #1258 is untouched too (and this removes the
composed-LD_LIBRARY_PATH block that only existed to keep the two
prepends from fighting). The preload is inherited by the Python backend,
where nothing links GStreamer and it is inert — the accepted cost.

Tests now assert both halves: the library IS preloaded, and the libdir is
NOT hoisted.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(appimage): verify the host GStreamer loads before preloading it

greptile P1, valid. The host core links GLib and the bundle ships GLib too,
resolved bundle-first — so a host GStreamer built against newer GLib than
we bundle fails its relocations and the app does not start at all. That is
strictly worse than the broken microphone this PR fixes. Taking host GLib
as well is not an option either: GLib is what WebKit is built against, so
pulling it from the host reopens #961/#1258.

Rather than predict the pairing, test it. The loader processes LD_PRELOAD
for any binary, so running `true` under the exact environment the app will
get is a complete check of whether the library loads there — a missing
dependency or an unresolved version tag ("version GLIB_2.84 not found")
fails it and nothing else runs. On failure the preload is skipped, the app
starts on the bundled core, and a warning names the mismatch so the user
has a thread to pull rather than a silent half-fix.

OMNIVOICE_APPRUN_PRELOAD_PROBE lets the suite choose the outcome, matching
the existing OMNIVOICE_APPRUN_WK_MARKER precedent; the new case fails if
the guard is removed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Palash Debnath
2026-08-04 12:48:47 +05:30
committed by GitHub
co-authored by Claude Opus 5
parent e60c5364ea
commit 810b598739
4 changed files with 280 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/install/linux.md
+56
View File
@@ -180,6 +180,62 @@ Tracking issues: [#62](https://github.com/debpalash/OmniVoice-Studio/issues/62),
[#961](https://github.com/debpalash/OmniVoice-Studio/issues/961),
[#1258](https://github.com/debpalash/OmniVoice-Studio/issues/1258).
## AppImage: "No microphone found" while the raw binary records fine
Recording from the AppImage fails with *"No microphone found. Connect or enable
a microphone and try again."* — but `pactl list short sources` shows your
microphones, `gst-launch-1.0 pulsesrc … ! fakesink` captures, and running
`frontend/src-tauri/target/debug/omnivoice-studio` directly records without
trouble. `GST_DEBUG=2` shows the real message:
```text
WARN GST_REGISTRY gst_registry_binary_check_magic:
Binary registry magic version is different : 1.23.90 != 1.3.0
GStreamer element appsink not found. Please install it.
```
Same shape as the blank-window problem above, in a different library. The
AppImage bundles the GStreamer **core** (WebKitGTK links it) but not its
**plugins** — those are loaded dynamically at runtime, so the packaging step
cannot see them to copy. The bundled core then reads *your* plugin directory,
whose plugins were built against *your* core, the version check rejects them,
and the scan produces nothing. `appsink` is one of the elements that goes
missing, and it is the one WebKit needs to hand over a capture stream — so
`getUserMedia()` reports no device. Your raw binary works because it uses your
core with your plugins, which agree.
**From v0.4.3 the launcher prefers your system's GStreamer**, which is the only
core that can match the plugins that will actually load. It does that by
preloading that one library (`LD_PRELOAD`) rather than by putting your system
library directory ahead of the bundle — your GStreamer shares that directory
with most of the system, so hoisting it would quietly replace every *other*
bundled library too. If your distro's GStreamer is itself broken and you would
rather fall back to the bundled core:
```bash
OMNIVOICE_PREFER_SYSTEM_GSTREAMER=0 ./OmniVoice.Studio_*.AppImage
```
The launcher checks first that your GStreamer can actually load alongside the
libraries the AppImage bundles — a system core built against newer GLib than we
ship would fail to load and take the whole app down with it, which is worse than
a missing microphone. If that check fails it prints a warning, keeps the bundled
core, and the app still starts (with capture still broken); building from source
avoids the mismatch entirely.
The AppImage also keeps its plugin-scan cache to itself, at
`~/.cache/OmniVoice/gstreamer-registry.bin`, rather than in the shared
`~/.cache/gstreamer-1.0/`. GStreamer names that shared file by architecture
alone, so two cores of different versions overwrite each other's — which both
makes this failure depend on whichever application ran last, and lets the
AppImage corrupt the cache every other GStreamer app on your machine reads.
If you set `XDG_CACHE_HOME`, the path follows it
(`$XDG_CACHE_HOME/OmniVoice/gstreamer-registry.bin`); `~/.cache` is the default
when it is unset.
Tracking issue: [#1333](https://github.com/debpalash/OmniVoice-Studio/issues/1333).
## .deb ffprobe conflict
<a id="deb-ffprobe-conflict"></a>