🚀 Ich entwickle eine Diktier-Engine in PHP (Flow + Symfony + Whisper.cpp)

der 22. Februar 2026

Die Entwicklung einer Diktier-Engine im Jahr 2026 ist trivial.

Interessanter ist es, eine saubere Architektur um eine Diktier-Engine herum zu entwickeln.

Dieser Artikel stellt Flowvox vor, ein MVP einer in PHP entwickelten Audio-Transkriptions-Engine, basierend auf:

Der Quellcode ist als Open Source verfügbar: 👉 https://github.com/darkwood-com/flowvox

Das Ziel war nicht einfach nur, Whisper zu benutzen. Ziel war es, die Pipeline ordnungsgemäß zu strukturieren.

Das Problem: Transkription ist nur ein Schritt

Eine minimale Sprachausgabe-Engine lässt sich wie folgt zusammenfassen:

Audio → Texte

In einem realen System treten jedoch mehrere Einschränkungen auf:

  • Aktivierung starten/stoppen
  • Fertigstellung der Audiodatei
  • Zustandsverwaltung des Rekorders
  • Orchestrierung der BĂĽhnen
  • Erweiterung der Nachbearbeitung (Zusammenfassung, LLM, Analyse)

Die Frage lautet dann:

Wie lässt sich eine saubere, skalierbare und kontrollierte Audiopipeline modellieren?

Technischer Stack

Das MVP basiert auf:

  • PHP 8+
  • Symfony
  • Symfony Messenger
  • Flow (Orchestrator)
  • ffmpeg (lokale Audioaufnahme)
  • whisper.cpp (lokale Open-Source-Transkription)

Keine Remote-API. Kein Cloud-Dienst. 100% lokale Transkription.

Allgemeine Architektur

Die Architektur ist in drei Abläufe gegliedert:

InputProvider → Recorder → Transcribe

Jeder Schritt ist isoliert und fĂĽr eine bestimmte Aufgabe verantwortlich.

InputProviderFlow

Verantwortung :

  • Achten Sie auf die Befehle voice:start und voice:stop
  • Ein VoiceControlEvent auslösen

CLI-Befehle lösen Nachrichten über Symfony Messenger aus.

Der Worker empfängt diese Ereignisse im Hintergrund und leitet sie an Flow weiter.

Diese Entkopplung ermöglicht Folgendes:

  • Feinsteuerung
  • Verwaltung mehrerer Sitzungen
  • Eine klare Trennung der Verantwortlichkeiten

RecorderFlow

Verantwortung :

  • Steuern einer VoiceRecorder-Instanz
  • Den Lebenszyklus eines ffmpeg-Prozesses verwalten

Der VoiceRecorder kapselt einen Systemprozess, der ĂĽber Folgendes gestartet wird:

Symfony\Component\Process\Process

Zentrales Problem:

Wie kann ich Start/Stopp korrekt steuern, ohne die Audiodatei zu beschädigen?

Drei Zustände werden explizit modelliert:

  • idle
  • Aufnahme
  • stopping

Während eines stop wird ein SIGINT an ffmpeg gesendet, um den WAV-Header ordnungsgemäß abzuschließen.

Der „Stopp“-Zustand verhindert Folgendes:

  • Der Doppelstart
  • Konkurrierende Konflikte
  • Unvollständige Dateien

Der Prozess wird kontrolliert, nicht einfach hingenommen.

TranscribeFlow

Verantwortung :

  • Sie erhalten eine fertige WAV-Datei
  • Starten Sie whisper.cpp
  • Erstellen Sie einen transkribierten Text

Whisper wird lokal ĂĽber die Befehlszeile ausgefĂĽhrt.

Das MVP bleibt bewusst einfach:

  • Kein Streaming
  • Keine Echtzeit-Chunking-Aufteilung
  • Eine synchrone Transkription

Ziel ist es, die Integration und Orchestrierung zu validieren.

Arbeiter und Orchestrierung

Die Engine läuft über einen Symfony-Worker:

php bin/console voice:worker

Dieser Arbeiter:

  1. Flow-Instanziierung
  2. Die FlĂĽsse aufzeichnen.
  3. Hören Sie sich Symfony Messenger an.
  4. Ordnet die AusfĂĽhrung der Schritte an.

VerfĂĽgbare Befehle:

voice:start
voice:stop
voice:worker-list

Der vollständige Feed lautet:

voice:start
→ Recorder démarre
→ voice:stop
→ Recorder finalise
→ TranscribeFlow s’exécute
→ Texte produit

Ohne einen externen globalen Staat.

Warum Flow?

Der Ablauf ermöglicht:

  • Eine pipelineorientierte Architektur
  • Strategien zur Eingabeverarbeitung (IP-Strategie)
  • Explizites Ereignismanagement
  • Eine klare Trennung zwischen Orchestrierung und Geschäftslogik

Das System ist nicht mit Whisper gekoppelt.

Whisper ist eine Implementierung. Der Fluss ist die Struktur.

Was der MVP genehmigt

  • Ordnungsgemäße Verwaltung eines Systemprozesses
  • Explizite Modellierung von Zuständen
  • Event-Orchestrierung
  • Skalierbarkeit der Pipeline

Dies ist kein Produkt.

Es handelt sich um ein architektonisches Fundament.

Mögliche Entwicklungen

Die nächsten natürlichen Iterationen:

  • Streaming nach Audio-Chunk
  • Parallele Transkription
  • Nachbearbeitung LLM
  • Integration Desktop
  • Mobile UnterstĂĽtzung
  • Multi-Modell-Batching

Diese Änderungen verändern jedoch nicht den Kern:

Eine klare Architektur. Eine meisterhafte Orchestrierung. Eine erweiterbare Pipeline.

Quellcode

Das Open-Source-Repository ist hier verfĂĽgbar:

👉 https://github.com/darkwood-com/flowvox

Beiträge, Anregungen und Feedback sind willkommen.

Abschluss

Die Entwicklung einer Sprachausgabe-Engine in PHP ist einfach.

Der Aufbau einer sauberen Architektur um eine Sprachengine herum ist interessanter.

Flowvox bestätigt ein Prinzip:

Die Transkription ist nur ein Bestandteil. Die Orchestrierung ist die eigentliche Struktur.