Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Request TTS and Diarizer opt-out traits: ASR-only consumers ship 1.0 MB of unreachable LuxTTS resources and compile 3.1 MB of unused subsystems (cf. #880/#888)

Chiusa
  • Qualcosa non va?
#990 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@Alex-Wengg ci sta già lavorando.

Dal 8/10/2026.

  • #1001 di @Alex-Wengg — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
52/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
swift
Ambito
build-system

Direzione di ricerca

Start with the existing NemoTextProcessing trait pattern in [email protected], then inspect the FluidAudio target's TTS and Diarizer sources and its TTS/LuxTts/G2p/Resources rule. The issue allows either conditioning within the target or separate trait-conditioned targets. Done means default builds retain current behavior, while opting out removes the TTS and Diarizer code and LuxTTS resources; validate with an ASR-only consumer and compare bundle and binary sizes.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Summary

ASR-only consumers unconditionally ship the LuxTTS G2P resources, and compile the TTS
and Diarizer subsystems, with no code path able to reach any of it. Could TTS and
Diarizer get the same opt-out trait treatment NemoTextProcessing received in #880 /
#888?

(Refiling #989, which I closed — it covered TTS only.)

Measurements

FluidAudio 0.17.5, release build of an ASR-only macOS app: Parakeet / Phonon-2 on the
ANE via AsrManager + AsrModels only. No TtsManager, no Kokoro, no LuxTTS, no
DiarizerManager — grep across the app's sources returns zero references to any of them.

FluidAudio_FluidAudio.bundle is 1.0 MB, and every byte is TTS:

File Bytes
luxtts_en_us_lexicon.tsv.zz 982,385
luxtts_en_us_g2p_aux.json 37,000
Info.plist 1,134

That comes from the unconditional

resources: [.process("TTS/LuxTts/G2p/Resources")]

on the FluidAudio target.

Source footprint of the subsystems, for scale against the one actually in use:

Subsystem Size
Sources/FluidAudio/TTS 2.4 MB
Sources/FluidAudio/ASR 1.3 MB
Sources/FluidAudio/Diarizer 728 KB
Sources/FluidAudio/VAD 60 KB

TTS is the largest subsystem in the library — nearly double ASR. In a prior unstripped
build of the same app, TTS symbols were roughly 9% of the binary's symbol table.

So an ASR-only consumer pays ~1.0 MB of provably unreachable resources, plus the compile
time and binary weight of 3.1 MB of TTS and Diarizer source.

Why traits rather than separate products

Separate FluidAudioASR / FluidAudioTTS products would break every existing
import FluidAudio. The trait approach already taken for NemoTextProcessing avoids
that: default-on preserves current behaviour exactly, and consumers who want a smaller
build opt out. Mirroring the existing pattern in [email protected]:

traits: [
    .trait(name: "TTS", ...),
    .trait(name: "Diarizer", ...),
    .default(enabledTraits: ["NemoTextProcessing", "TTS", "Diarizer"]),
]

with those sources, and the .process("TTS/LuxTts/G2p/Resources") resource rule,
conditioned on the matching trait.

I appreciate the resource rule is the harder half. Conditioning source files and
resources on a trait within a single target is more awkward than conditioning a
dependency on a binary target, which is what #880 needed. If the practical route is
splitting TTS and Diarizer into their own trait-conditioned targets, that is equally good
from a consumer's point of view.

Happy to test a branch against an ASR-only consumer and report the resulting bundle and
binary sizes.

Lingua principale
Swift
Stelle
3k
Fork
451
Merge medio
1g 1h
PR unite (30g)
57

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di FluidInference/FluidAudio

Tutte le issue di FluidInference/FluidAudio

Issue simili

Altre issue su Swift

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.