Generic TTS-Wrapper

Moin Modul-User,

folgende Idee ist mir gekommen, als ich über eine integration der TTS-Funktionen in meinem SqueezeBox & OnkyoAVR Modulen nachgedacht habe.

Ein universeller TTS-Wrapper, welcher als Bindeglid zwischen anderen Modulen und einem TTS-Modul hängt.
Somit könnten alle Modul-Entwickler eine und die gleichen Funktionen nutzen um TTS in ihren Modulen zu verwenden.
Unabhängig davon welche TTS-Engine (oder Modul) sich dahinter verbirgt.

Vorteile wären auch, das wenn eine neue TTS-Engine hinzukommt, nicht jeder sein Modul ändern muss, sondern nur der Wrapper aktualisiert werden muss.

Die Umfrage die diesem Thema anhängt, ist nicht per Tap-A-Talk zu erreichen :wink:

Michael

Klingt sehr gut :slight_smile:

Dann müsste man nur in diesem Wrapper auswählen „TTS - Google“, „TTS - InstanzID“, „TTS - Amazon“ oder was da noch kommen mag. Zusätzlich im Wrapper noch einen Pfad eingeben, wo die Sound-Datei abgespeichert werden soll. Eventuell müsste man noch das Sound-Format (MP3/WAV) irgendwie mit unterbringen.

Und die Rückgabe an das Skript könnte dann Pfad + Dateiname sein, wo die „fertige“ Sound-Datei liegt?! Vlt. sogar noch mit Zusatzinfos wie Abspieldauer und keine Ahnung?!

Grüße,
Chris

Ja, die InstanzID der dahinter hängenden ‚echten‘ TTS-Instanz, muss der User in den Einstellungen des Wrappers hinterlegen müssen.

Welcher Typ dort eingetragen wird ist egal, das kann das Modul dann selbst herrausfinden (Modul-GUID der eingestellten Instanz).

Ebenso können erstmal nur Funktionen genutzt werden, welche alle TTS-Typen mitbringen.
Über eventuelle Erweiterungen des Umfangs darüber hinhaus, wie z.B. Länge der Wiedergabe oder Dateiformat muss man dann im Einzelfall entscheiden, wie aufwendig Dies zu implementieren ist.

Darum auch diese Umfrage, mit der Option der Beteiligung.
Ich möchte ungern am ‚Ziel‘ vorbeischießen.
Und das passiert bestimmt, wenn ich nur ‚meine‘ Anforderungen umsetzen würde :smiley:

Michael

Evtl. könnte man auch noch eine „Fallback-Funktion“ einbauen.

Angenommen man wählt als 1. die Google TTS API aus und diese hat wieder was geändert oder keine Ahnung, auf jeden Fall wenn die 1. Wahl nicht funktioniert, dann wird automatisch die 2. Wahl (z.B. Amazon TTS API) verwendet. Oder für Windows auch mit „Offline-Fallback“, falls keine Internetverbindung vorhanden ist, auf die MS-TTS-API… :cool:

-Chris-

Hi,

finde ich super!

Da könnte man darüber nachdenken, ob man den Pfad als config im Wrapper oder im jeweiligen TTS-Modul hätte…

Warum? Spezielle einstellungen muss man dann halt in der Config der TTS Instanz festlegen.

Was ich mich gerade noch gefragt habe:
Haben nicht bestimmt TTS Dienste die Limitation, dass nur eine bestimmte Zeichenlänge unterstützt wird?
Da müsste man evtl. noch in Häppchen teilen.

Auch das Aufräumen der Dateien sollte man im Blick behalten…

Gruß,
Thorsten

Jupp, Google lässt nur 100 Zeichen zu :-
>> IPSSonos - Seite 14

Aufräumen? Joa, oder einfach überschreiben. Wenn alle die gleiche Ausgabe-Datei verwenden vom Namen?!

-Chris-

Hi,

Dann kannst Du aber niemals mehrere Ansagen gleichzeitig nutzen.
Eher mit GUID als namen ablegen und nach 2 Stunden wieder löschen, oder so.

Gruß,
Thorsten

Stimmt, nur weil ich nie mehrere Ausgaben gleichzeitig nutze, kann ein anderer es ja trotzdem nutzen :smiley: Wer weiß was er hier für riesen Gebäude bei den IPS`lern gibt :slight_smile:

Und wenn eh Pfad + Dateiname übergeben werden, wäre der Dateiname auch beliebig wählbar… Dann wäre es vlt. noch besser, wenn man einen bestimmten Suffix verwendet, meinetwegen die GUID, und am Ende aus Datum/Zeit/Mikrosekunden noch einen Prefix anhängt, dann kann man wie wild TTS benutzen :smiley: …und es kommt sich nichts in die Quere.

Also würde man den Wrapper ansprechen mit z.B. „$PfadUndDateiname = TTS_Modul(„Ich bin ein Text“);“ und kann danach in seinem Projekt damit beliebig weitermachen?! Oder was schwebt den Profis da so vor? :slight_smile:

Grüße,
Chris

Ihr seid schon viel weiter als ich war/bin :wink:

Wenn ich es mal ganz pragmatisch betrachte:

[ul]
[li]Es gibt aktuell nur 2 TTS-Module (VoiceRSS und Windows-TTS-API, welches aber nur unter Windows funktioniert)
[/li][li]Kleinster gemeinsamer Nenner beim Format ist aktuell nur WAV
[/li][li]Kleinster gemeinsamer Nenner beim Format von Funktionen welche diese Module bereitstellen ist ->GenerateFile
[/li][/ul]

Zuerst bräuchte man also erstmal noch ‚mehr‘ TTS-Module.
Google braucht man glaube ich nicht mehr umsetzen, soll ja wohl eingestellt werden.
Vor einer eigenmächtigen Umsetzung der AmazonTTS sollte man den ‚Urheber‘ der Idee (Titus) mal nett fragen.

Einschränkungen wie ‚Anzahl der Zeichen/Wörter‘ oder auch Dateiformate, sollten in den jeweiligen TTS-Modulen eigenständig umgangen werden.

Wenn dies nicht möglich ist, wie bei dem ‚Format‘ der Windows-TTS-Instanz, so kann man überlegen ob man versucht dies im Wrapper zu lösen.

Den ‚Benutzer‘ des Wrappers solltes es selbst überlassen sein, oder er Rohdaten, ein Filenamen oder ein MediaObject erzeugt bekommt. Nich alles ist für jedes Device-Modul zu gebrauchen.

Aufräumen muss man in jedem Fall.
Also noch eine Art GenTTS_CleanUp();

Zur Identifizierung könnte man auch ‚einfach‘ den Aufrufer des Wrappers nutzen.
Also dessen ObjectID + ggfls. noch den PHP-Slot in welchen die PHP-Instanz vom Modul gerade läuft.

Aktuell habe ich so viele Ideen, aber zu wenig Zeit :wink:

Ich werde aber mal versuchen, in den nächsten Tagen, eine Art Grundgerüst auf GitHub stellen.
Sowie eine Art Pflichtenheft was dieses Modul mindesten können muss.
Dann können wir ja mal im Detail diskutieren.

Michael

Die Idee finde ich super!

Vielleicht noch eine Idee, die ich in meinem Skript so schon umgesetzt habe.

Der Dateiname der generierten Sprachausgabe ist der MD5-Hash des gesprochenen Textes. Ich speichere die Dateien in einem Ordner „tts-cache“ unterhalb von user/webfront. Wenn eine Sprachausgabe von einem Skript angefordert wird schaue ich erstmal dort nach ob die Datei schon existiert. Nur wenn das nicht der Fall ist wird die Datei in der Cloud angefordert.

Bei mir sind es doch fast immer nur die gleichen Ansagen die ich brauche, das reduziert die Anfragen an Amazon / Ivona doch massiv.

Die Idee mit dem Hash und caching finde ich auch sehr gut.

Aber warum legst du das unter /webfront/user ?
Das das einen besonderen Hintergrund, den ich gerade nicht verstehe ?

Was bei IPS 4 ganz nett ist, das MediaObjecte im RAM gespeichert werden können. Dies schont die ganzen FlashMedien.

Anderseits, könnte man es auch einfach in den Temp-Ordner des jeweiligen OS werfen.

Michael

Das mit dem Cache ist eine gute Idee :slight_smile: Grad bei Leuten mit aktuellem Trafficmangel hust :rolleyes: …wäre das wirklich praktisch und hätte auch allgemein einen Speed-Vorteil, weil die Zeit zum Generieren/Downloaden weg fällt :cool:

Nur den Cache ewig aufheben wäre in meinem Fall auch eine eher schlechte Idee, weil Tagesmeldung mit Datum/Wetter/Müll gibt es immer nur einmal. Vielleicht sollte man bei der Übergabe an den Wrapper festlegen können, ob die Datei im Cache gespeichert werden soll, oder ob die Datei nach X Minuten oder nach X Tagen, … wieder gelöscht wird?!

-Chris-

Grundsätzlich wäre das eine Aufgabe des jeweiligen TTS-Modules.

Michael

Aber das Flag müsste im Wrapper bedacht werden, damit man es (optional) an das TTS Modul übergeben kann.

-Chris-

Ja, hat es. Meinen Peaq- / Pure-Lautsprechern kann ich nur HTTP-URLs unterschieben und wenn die Datei unterhalb von webfront/user liegt kann ich sie direkt per http ansprechen.

Die zweite Idee, im Aufruf das caching deaktivieren zu können, finde ich auch sinnvoll.

Was ich in meinem Skript auch noch umgesetzt habe ist die Möglichkeit statt einer direkten Ausgabe an die Speaker nur die URL der Sprachdatei zurückgeben zu lassen. Dies nutze ich häufig wenn ich mehrere Ausgaben per M3U-Datei zusammen füge.

Ja genau, das meinte ich ja damit das man verschiedene Funktionen mit entsprechenden Rückgabe-Werten braucht.

Für den Receiver brauche ich glaube ich auch eine URL, für die SqueezeBoxen bin ich mir gerade unsicher ob die Datei ‚nur‘ vom dazugehörigen Server oder auch von den Geräten erreichbar sein muss.
Und über Sonos weiß ich gar nix :wink:

Ist wirklich nicht einfach welches Funktionalität man nun wo läßt. Aber um einfach mal anzufangen, ist weniger wohl erstmal ‚mehr‘.

Michael

Bei Sonos kann ich Musikdateien von einem Fileshare (wenn in Sonos eingebunden - siehe Erklärung unter SonosBY Skript) abspielen. Aber Radiostationen laufen auch direkt über eine URL (siehe Sonos Modul von kugelberg), also sollte auch anderer Kram über URL abspielbar sein, hab ich aber noch nie getestet.

-Chris-

Folgende Tabelle ist mal nebenbei entstanden.
Die Lücken oder Fragezeichen bei Ivona & Google müss aber noch gefüllt werden.
Wer Infos hat, immer her damit :smiley:
Um einen Encoder MP3 <–> WAV wird man wohl nicht rumkommen… :frowning:
Dies wird bestimmt ein ‚Spaß‘ für ein multi-OS Modul.

Übersicht verfügbarer/möglicher Module und deren ‚Fähigkeiten‘:

Legende :X : vorhanden

  • : nicht vorhanden
    ? : Info benötigt
Modul: Win-TTS VoiceRSS Ivona / Amazon Google-Translate
Verfügbarkeit:
Offline X - - -
Online - X X X
Formate:
WAV X X ? ?
MP3 - X X X
OGG - X
AAC - X
CAF - X
Datenrückgabe:
Datei X X X X
RohDaten (Base64) - X
IPS-MediaObject - X
HTTP(S)-URL - - X
Cache:
nicht benötigt X
eingebaut - X
Limitationen:
Anzahl Zeichen pro Request - 100 kB ? 100 Byte
Anzahl Anfragen - 350/day ? -
Anzahl Wörter - - ? -

Google TTS erstellt ein MP3 mit einer Bitrate von 32Kbps und 16KHz.

Grüße,
Chris