automator:
Spracherkennung wäre schön gewesen, braucht aber wohl wirklich zuviel Rechenpower.
Spracherkennung oder Sprachaktivitätserkennung?
Für ersteres sei dir eine potente ARM Plattform empfohlen, auf die der Julius läuft.
Julius ist ein leistungsfähiger Spracherkenner, OpenSource.
Das Vokabular muss man sich selber stricken, wenn man nicht auf das Demomaterial zurückgreifen will.
Alternativ gibt es noch den TIESR:
https://gforge.ti.com/gf/project/tiesr/
OpenSource und vor allem fixed point basiert. Damit könnte man vielleicht auch auf weniger potenten Plattformen seinen Spaß haben.
Sprachaktivitätserkennung: ITU G.729 Annex B, der Standard und der Sourcecode der Referenzimplementierung sind frei verfügbar.
Sonderlich gut das ist das Teil aber nicht.
Damit ist nur die Erkennung: Sprache/keine Sprache möglich, das ist kein Spracherkenner!
Nur zwei Töne erkennen:
Das Signal in zwei unterschiedlichen Frequenzbändern betrachten, z.B. mit zwei Bandpassfiltern zerlegen.
Zur Erkennung: Betrachtung des Pegels über ein mittellanges Zeitfenster, z.B. 300-500 ms.
Bandpassfilter: Irgendwas rekursives zweiter Ordnung sollte genügen, wenn die Töne weit genug auseinander liegen.
Den Pegel immer blockweise berechnen, ich schlage mal Blöcke von 20ms vor. Anschließend noch den Pegel über 300-500ms mitteln, da bietet sich ein rekursives Tiefpassfilter erster Ordnung an.
Sinnvolle Schwellwerte auswählen. Wenn Pegel im Band drüber, dann wird angenommen, dass jemand gepfiffen hat.
Vielleicht noch ein Hysterese-Mechanismus, damit das Ding nicht bei jedem Fliegenhusten losmarschiert.
Wenn du zwei A/D Wandler hast bzw. einen Stereowandler, dann könntest du deine Bandpassfilter auch analog aufbauen. Spart dir dann etwas Rechenleistung vor allem wenn es etwas steiler werden soll. ;-)
