[Shivay Lamba (shivaylamba)]

Summary

Add streaming text-to-speech to the existing qairt plugin using the companion
pipeline in qualcomm/geniex-qairt-plugin#81.

The implementation now uses that runtime's Model, Graph, QNN HTP loader,
buffers and profiling. The separate phonon_qnn plugin and external Gradium QNN
engine dependency have been removed. Phonon's acoustic scheduling lives in the
QAIRT model implementation; this SDK change is its streaming API adapter.

• Additive C TTS API, optional versioned factory, Python/Go and raw Android
  JNI/Kotlin surfaces. Existing Plugin vtables remain unchanged; plugins without
  the optional speech factory return NOT_SUPPORTED.
• GenieXTTS selects qairt by default. Use the same process-wide QAIRT runtime
  configuration and log sink as LLM/VLM. An optional runtime field only asserts
  consistency with the selected runtime; it cannot switch providers per model.
• Stream mono float PCM, cancel and reuse sessions, return per-request graph
  counters and accelerator timings. Strict verification requires positive QNN
  accelerator events for both prefill and step; no CPU/GPU retry.
• CPU text preparation, acoustic scheduling, state copies and audio delivery
  remain host work. Compiled context binaries must match the target SoC and
  runtime. GGUF alone is not a QAIRT pipeline input.

See sdk/plugins/qairt/README.tts.md and the companion pipeline's
models/phonon/VALIDATION.md for setup and measured scope. No weights,
credentials, generated audio or additional QAIRT payloads are introduced.

Validation of this revision

Windows ARM64 Snapdragon X Elite, GenieX ARM64 LLVM toolchain (Clang 22.1.8),
QAIRT 2.45.0.260326, SC8380XP contexts, Phonon 31M and 40M:

• Full SDK build with existing QAIRT LLM/VLM sources plus TTS.
• Two C API/path contract suites passed, including optional-factory compatibility.
• 62/62 Python unit tests passed, including all six native TTS contract tests.
• 29 real-device Python checks passed: CPU/GPU rejection, wrong SoC, missing
  frontend, conflicting runtime assertion, locked shared selection, streaming,
  cancellation, callback exceptions, invalid voice recovery and multi-chunk text.
• Inspected the running process: HTP/System loaded from the selected QAIRT 2.45
  installation, with no QNN CPU/GPU provider.
• Eight SDK WAVs passed format/nonsilence checks. Identical-input first WAVs
  match the Gradium PR-273 reference runner's length with max PCM16 difference 1
  for both models. Every successful run reports positive accelerator timings
  for both graphs.
• Companion QAIRT build: 399 CPU unit tests passed and 100% patch coverage for
  the new generic pipeline; device lifecycle tests passed for both models.
• Clang-format 20, Ruff and Git whitespace checks passed for changed sources.

Observed warm Python first-PCM medians: 31M 6.99 ms (RTF 0.0540), 40M 9.02 ms
(RTF 0.0617), last three of four requests per loaded model. These exclude model
initialization and speaker playback and are not performance guarantees.

Remaining scope

This remains a draft SDK modality proposal dependent on the companion pipeline
review/merge. The submodule pin is that tested companion commit and should be
updated to its merged upstream revision before landing.

Android/Linux/VENTUNO Q hardware, current Android packaging/linking and
concurrent LLM/TTS execution have not been validated in this revision.
CLI speech routes, model catalogue / pull integration and GGUF CPU/GPU TTS
are outside this implementation. No claim is made that it runs on arbitrary
devices without compatible compiled contexts, runtime and drivers.

Closes: N/A; companion implementation of the QAIRT-pipeline direction requested here.

[David Qian (Davidqian123)]

Hi Shivay Lamba (@shivaylamba), thanks for your contribution! For now, we are not going to add one extra plugin in GenieX, because it will increase a lot of maintanence efforts. I wonder if phonon_qnn also runs TTS model in QAIRT path? If so, we prefer to add A TTS pipeline inside geniex-qairt-plugin and it would reuse the existing QAIRT runtime handling. You could either contribute to geniex-qairt-plugin or maintain a local GenieX fork, thx!

[Shivay Lamba (shivaylamba)]

Thanks for clarifying the preferred direction. I've implemented it in qualcomm/geniex-qairt-plugin#81:

• TTSPipeline plus a Phonon model implementation using the existing Model/Graph, QNN HTP initialization, buffers, runtime selection and logging.
• Shared QNN BASIC profiling for per-request accelerator timings. No separate Gradium QNN engine or backend loader.
• Both Phonon 31M and 40M work through the shared runtime. CPU/GPU requests are rejected, with no provider retry.

I've also updated this draft to consume that pipeline through the existing qairt plugin and removed phonon_qnn. The additive streaming speech API remains, with an optional versioned factory so existing plugin vtables stay unchanged.

I tested locally on the Windows ARM64 X Elite using the GenieX LLVM toolchain and QAIRT 2.45 with SC8380XP contexts:

• Full QAIRT/SDK builds; 399 CPU unit tests, 62 Python unit tests, two C API contract suites and 29 device checks passed.
• Cancellation/reuse, multi-chunk speech, invalid inputs and positive accelerator timings for both graphs on both models.
• Loaded-module inspection confirmed the selected HTP/System libraries, with no QNN CPU/GPU provider.
• Generated WAVs passed format/nonsilence checks; compared with Gradium's PR-273 reference runner using identical input/seed, both models have matching lengths and maximum PCM16 difference of 1.

Warm first-PCM callback medians were 6.99 ms / RTF 0.0540 (31M) and 9.02 ms / RTF 0.0617 (40M) over three warm requests each. These exclude model initialization and speaker playback. Detailed methodology and reproducible tests are included in the companion change.

Android/Linux/VENTUNO Q hardware and concurrent LLM/TTS execution remain unvalidated in this revision. CLI/model-catalogue integration is also outside this change. I'll keep this SDK draft dependent on the companion pipeline review and update its submodule pin to the merged revision before landing.