Wie füttern wir ein Fake-Telefon mit Soundfiles?

1.) Vieleicht wäre das mit nem USB Telefon zu bewerkstelligen .
2 Meine Fritzbox kann ich als wecker mißbrauchen leider spielt sie aber kein soundfile ab ich kann mich aber erinnern das es so was mal für windows in zusammenhang mit ner Auerswald TK anlage funktionierte , auch als message system wie ne virtuelle T-NET box wenn mann da was hinterlässt dann ruft die alle 4 minuten bei jemanden an bis einer abnimmt.

...

Hallo kodjo,

also - ich hab mich etwas verspielt in die Sache. Die Python Geschichte wird auch nicht so einfach gehen. Ich leite auf das cu.modem um und es wählt nicht. Im system.log passiert zwar was, aber ich bin aus dem Quellcode des Skripts nicht schlau geworden, wie überhaupt gewählt wird. Mit dem ZTerm kann ich wählen. Also wählen kann man auf mehrere Arten - das ist nicht das Problem. Telefonanlagen sind auch nicht sooo teuer.

Dann habe ich CoMa X ausprobiert. Das kann man gemütlich testen. Mit dieser SW kann man auch das Modem testen. Apple scheint nur in den Performas Voice-Modems verbaut zu haben. Also Essig mit dem Mini. Das externe Apple USB Modem könnte aber gehen. Ebenso der miniVigor. Auf der Seite sind noch ein paar andere Modems aufgeführt die gehen.

Mit einem externen Modem könnte wiederum das Python Skript gehen, wenn das mal ein Python Programmierer näher unter die Lupe nimmt.
Eventuell fehlt da ja noch was...

Die wahrscheinlich genialste SW für diesen Job, bei der gleich ein USB Adapter mitgeliefert wird ist Phlink Man beachte die umfangreiche Skriptsammlung unter Resources

Keeps playing back to the caller fragments of what the caller just said.

Zum Vergrößern anklicken....

lassen sich bestimmt gaaanz lustige Sachen damit anstellen...
Ist nicht gerade billig - aber erspart einen Haufen Zeit und Gefrickel.

Da Du die Telefonplatine zerstört hast, werden Dich jetzt die folgenden Links vielleicht ärgern

1. http://www.dplay.com/tutorial/Mac2tel.html
2. http://www.dplay.com/tutorial/hifi2mac.html#tips

Die Schaltungen wären wohl dazu geeignet, über AppleScriptfähige Bordmittel Dein Problem zu lösen. Sprich über Internet Verbindung anwählen lassen (Telefonanlage ) Status verbunden ließe sich abfragen. Wobei das nicht ideal ist, da ja ein vermeintlicher ppp Server angerufen wird und dann piept es im Telefon. Ebenso schlecht wäre das Faxgezwitscher. ZTerm müsset man dann über GUI Scripting ansprechen (wobei es da schwierig wird den Staus abzufragen). Ebenso den wxDialer. Ideal wäre das Modem über das Terminal direkt anzusteuern und abzufragen das wäre dann mit AppleScript auch nicht das Superproblem denke ich mal. Man könnte auch von AppleScript aus ein Python Skript aufrufen. Abspielen und Aufnehmen (hat Dein Mini LineIn?) wäre dann mit QuickTime machbar.

Also ich tendiere stark zu der Phlink - Lösung...

Gruß Andi

Andi schrieb:

Mit einem externen Modem könnte wiederum das Python Skript gehen, wenn das mal ein Python Programmierer näher unter die Lupe nimmt.

Die wahrscheinlich genialste SW für diesen Job, bei der gleich ein USB Adapter mitgeliefert wird ist Phlink Man beachte die umfangreiche Skriptsammlung unter Resources lassen sich bestimmt gaaanz lustige Sachen damit anstellen...
Ist nicht gerade billig - aber erspart einen Haufen Zeit und Gefrickel.

Zum Vergrößern anklicken....

Ja, find ich auch interessant. Wenn Du die Modem-/Telefonanlage-Lösung weiter verfolgst, gibt es irgendwann vielleicht 2 Lösungen. Bei mir reicht die Energie hoffentlich wenigstens für den Weg, auf den ich mich gerade konzentriere.

Andi schrieb:

Da Du die Telefonplatine zerstört hast, werden Dich jetzt die folgenden Links vielleicht ärgern
1. http://www.dplay.com/tutorial/Mac2tel.html
2. http://www.dplay.com/tutorial/hifi2mac.html#tips
... Die Schaltungen wären wohl dazu geeignet, über AppleScriptfähige Bordmittel Dein Problem zu lösen. Sprich über Internet Verbindung anwählen lassen (Telefonanlage ) Status verbunden ließe sich abfragen ...

Zum Vergrößern anklicken....

*Smile*. Da war ich auch mal vorbeigekommen. Status verbunden abfragen ... das ist ein Punkt der für ne Anlage spricht.

Ich muß mir jetzt jedenfalls erstmal zwei 70er/80er Jahre "FernmeldeTischApparate" FeTAp 751, 791 oder 871 besorgen, die sind leicht manipulierbar (für den Anfang).

Der 1.42 GHz Mac Mini übrigens hat nur Audio OUT. Über USB iMic anschließen löst das Problem normalerweise, bietet Audio OUT und IN.

...

Hallo kodjo,

tja - Lösung 1 scheint fast zu stehen. Mit CoMa X und dem miniVigor kann ich ein Analogtelefon anrufen und eine Voicenachricht im aiff-Format absenden. Letztes Problem ist ein Analoges Voice-Modem um mit der billigen Telefonanlage eine Nebenstelle anzurufen. Die SW ist nur teilweise skriptfähig aber der UI Element Inspector macht gute Hoffnung.

Im DSL- und Voice-over-IP-Zeitalter sollte sich ein passendes Modem und Telefonanlage (eventuell über einen PC vorkonfiguriert) zusammen für unter 50€ beschaffen lassen. Die Telefonanlage sollte halt auch nur intern funktionieren.

Ob Du dem Programmierer von CoMa X ein paar € für eine abgespeckte Version seiner SW für nur Dein Modem zukommen läßt, bleibt Dir selbst überlassen...

Übrigens der wxDialer funktioniert mit meinem K700i - aber das tut das Adressbuch auch...

Gruß Andi

Andi schrieb:

Letztes Problem ist ein Analoges Voice-Modem um mit der billigen Telefonanlage eine Nebenstelle anzurufen. Die SW ist nur teilweise skriptfähig aber der UI Element Inspector macht gute Hoffnung.

Zum Vergrößern anklicken....

Gratuliere!

Auf meinem Trip bin ich auch weitergekommen: Das Audio-Out-Telefon funktioniert. Lauter Sound vom Mac im Telefonhörer und die gedrückte Hörergabel bringt ein verwertbares Signal. Genau die russisch-polnische Raumfahrttechnik, die ich bewundere. Beschreibung mit Bildmaterial heute abend.

Die Softwaresteuerung fehlt noch, aber die Voraussetzungen dafür sind nun sichtbar. Am Besten die Steuerung so primitiv und fehlerresistent wie die Hardware. Das Ziel wäre: Ordner anlegen, Script starten, allgemein vorhandene Mac Freeware wird automatisch konfiguriert, Anlage ist benutzbar. Der Weg dahin wird noch was dauern.

kodjo kaputnik

Hardwarehack um Mono-Soundfiles mit einem Mac in einem alten Telefon direkt abzuhören:

Man nehme einen Mac und ein altes Telefon. Audio-Ausgang am Mac ist üblich. Falls kein Audio-Eingang vorhanden, bietet das iMic über den USB Anschluß. Als Telefon gut geeignet sind aufschraubbare Apparate der alten Deutschen Bundespost (FeTAp = FernmeldeTischApparat) z.B. der Serie 82-2.

Weitere Zutaten (individuell variierbar): 1 Seitenschneider, 1 Schraubenzieher, je 1 Stereo Klinken mit Kabelrest für Audio Out und Audio In, 1 Vieradriges Kabel vorschriftsmäßig mit dem Telefon verbunden, einige Krokodil- oder Lüsterklemmen (provisorisch bis zum Verlöten).

1. Von Mac Audio Out kommen zwei Adern, ummantelt mit Abschirmung/Masse. Eine Ader wird mit der gelben, die andere mit der grünen Ader der Leitung in das Telefon verbunden. Dabei keine Kontakte der Adern zu Abschirmung/Masse zulassen. Die Leitungen Gelb und Grün von Audio Out und auch vom Telefon in den Hörer, werden vor den Platinensteckern im Telefon durchtrennt und direkt miteinander verbunden, so daß Audio Out direkt zur Hörermuschel läuft.
- Siehe Abbildung FeTAp-Man: Rechts kommt durch das Telefonkabel über Grün/Gelb Audio vom Mac rein und wird nach links zum Hörerkabel verbunden, so daß Audiofiles im Telefonhörer gehört werden können, z.B. Webradio.

2. Ein Signal durch das Abnehmen des Telefonhörers ist die Voraussetzung für eine Softwaresteuerung. Das Signal beim Auflegen wird bei manchen Installationen für ein Fake-Telefon nicht gebraucht, da nach Abspielen des 2. Soundfiles der Benutzer sowieso bald auflegt oder irgendwann wieder ein Klingeln aus dem Hörer ertönt. Durch das Abnehmen des Hörers wird das Abspielen des für den Benutzer bestimmten Soundfiles gestartet.

Die Hörergabel erzeugt ein Knacken beim Abheben, wenn Sie wie folgt angeschlossen ist: Die Abschirmung einer Ader von Audio-In mit der braunen Ader verbinden, die zur Hörergabel läuft. Die von dort kommende weiße Ader wird mit der Audio-In - Ader verbunden, deren Abschirmung nicht benutzt wird. Falls nun im Mac ein unsauberes Brummen ankommt, das stärker ist, wenn der Hörer die Gabel herunterdrückt, müssen an beiden Adern nur die Verbindungen zu Abschirmung und Ader getauscht werden, so daß eine relativ leise Frequenz im Mac ankommt, aber bei Drücken und Losslassen der Hörergabel ein lautes Knacken erzeugt wird. Es soll erkannt und zur Steuerung benutzt werden.
- Siehe Abbildung 'Knacken': Hier wurde die Hörergabel gedrückt und wieder losgelassen.

Die Anforderung für den Steuerungsablauf habe ich hier schon vorher gepostet. Hat jemand noch Verbesserungsvorschläge auf dem Hardwarelevel und Ideen für die Steuerungssoftware?

kodjo kaputnik

kodjo schrieb:

...Ein Signal durch Abnehmen oder Auflegen des Telefonhörers ist die Voraussetzung für eine Softwaresteuerung....Brummtonüber Audio aber nur in den Mac...Signal erkennen und zur Steuerung einsetzen läßt, ist es gut...

Zum Vergrößern anklicken....

Kann man die Verkabelung so machen dass das Mikro dass sich ja in der Sprechmuschel befindet, korrekt an LineIn verdrahtet wird, also auch als in LineIn eingestöpseltes Mikro von OS X erkannt wird? Ob direkt oder via iMic dürfte keinen Unterschied machen.
Wenn das klappt, dann sollte sich der ganze Spaß mit Hilfe der Speakable Items triggern lassen können.
Folgendes Beispiel mit Applescript hat bei mir wie folgt funktioniert:


Speichern als Programm (nur ausführbar, kein Startdialog), im Ordner /Users/Username/Library/Speech/Speakable Items z.B. als "Hello.app".

In den Systemeinstellungen/Sprache unter Spracherkennung/Einstellungen folgende Parameter eingestellt: Das Mikrofon das das Signal verarbeiten soll (Kalibrieren nicht vergessen). Methode: Kontinuierliche Spracherkennung mit Schlüsselwort, Schlüsselwort wird: Nur optional vor den Befehlen benötigt.
Bei Spracherkennung/Befehle nur "Globale" eingestellt.
Dann die Speakable Items eingeschaltet.
Wenn ich jetzt "Hello" sage wird das obige Script abgearbeitet.
Der SpeechRecognitionServer selbst ist auch skriptbar (und unter: "/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/Resources/SpeechRecognitionServer.app "zu finden). Mit einer list of choices müssten so auch mehrere Reizworte realisierbar sein, da man nicht genau weiss was und wie die Person die den Hörer abnimmt sagen wird.
Auf diese Art müsste sich eigentlich der ganze Prozess in Gang bringen lassen, also:

- Hörer abnehmen, Reizwort sagen
- Reizwort triggert den Stop des Klingelloops (natürlich nicht im ersten Durchlauf, sondern erst in den weiteren) und das Abspielen der Files (evtl. nicht mit iTunes sondern einer schlankeren Lösung, vielleicht sowas wie der Theaterplayer (https://www.macuser.de/forum/showthread.php?t=77248&highlight=Theater+Player) aber beeinflussbarer).
- Das Ende der Datei triggert den Countdwown zum Klingelloop.
- Klingelloop läuft, jemand hebt ab, meldet sich (mit Reizwort)
usw...ad infinitum...

Je nach Lösung wie die Files abgespielt werden bietet sich dann auch eine passende Lösung zum "Nachfüttern" via Netz.

THE BIG PLUS: Nur Bordmittel zur Triggerung, keine 3rd-Party Software.

Grüße,
Flo

@Flo, wegen Deinen hoffentlich humorvoll gemeinten Vermutungen über mich: Nimm mal an, ich versuche etwas Positives. Ich bin kein Techno-Überflieger und habe auch nicht viel Ahnung von Forum-Regeln, sondern erarbeite mir die Sachen hier gerade erst selbst.

Ich möchte die Diskussion nicht damit behindern, daß ich meine Lösung anderen gegenüberstelle, sondern es gibt viele Möglichkeiten, und die anderen sind für viele Zwecke besser.

Mir ist aber auch klar geworden, daß ich für meine Installation eine exakte Steuerung brauche. Für mich ist der Hardware-Teil so ungefähr fertig, auch dank der Entwicklung des Threads. Bleibt als Hauptroblem für mich die Software-Steuerung. Ist es nicht naheliegend, dort wo die Software-Spezialisten sich austauschen, nach möglichen Lösungswegen zu fragen? Es kann hier dann in der praktischen Anwendung erklärt werden und drauf hingewiesen werden, wo es nachzulesen ist.

Ich wollte Deinen Vorschlag, den ich reizvoll finde, auch weil ich mit Speakable Items schon damals auf einem PPC 8500 gespielt habe, praktisch mit einem Telefonhörer ausprobieren, und werde dafür auch einen aufschrauben. Aber ich hab' ein Geschäft am laufen und immer Terminstreß.

kodjo

kodjo schrieb:

@Flo, wegen Deinen hoffentlich humorvoll gemeinten Vermutungen über mich: Nimm mal an, ich versuche etwas Positives.

Zum Vergrößern anklicken....

Und was interessantes, find ich gut. Deswegen find ich die "Umzieherei" nicht besonders ressourcenschonend.

kodjo schrieb:

...mit Speakable Items schon damals auf einem PPC 8500 gespielt habe, praktisch mit einem Telefonhörer ausprobieren, und werde dafür auch einen aufschrauben. Aber ich hab' ein Geschäft am laufen und immer Terminstreß.

Zum Vergrößern anklicken....

Das kenn ich gut, eilt ja nicht. Ich dachte nur dass die Lösung mit den Speakable Items etwas einfacher ist, nachdem ich lange erfolglos nach einer einfachen und günstigen Audio-In-Triggerung gesucht habe.
Ich konnte keinen besseren Audiotrigger als die SI finden.
Soweit mal von meiner Seite. Vielleicht finden sich ja noch andere/bessere Lösungen. Oder weitere Ideen zu den SI.

Grüße,
Flo

P.S.: Hallo Mods, falls der Thread doch wieder umzieht, wäre es hilfreich dann hier wenigstens gleich richtig dicht zu machen, und den Link zum neuen Thread nicht zu vergessen. Nicht dass das so geht wie beim ersten Mal.

Primitives Wissen aus vergangenen Analogzeiten im Kodjo Kurzschluß Nachtlabor neu entdeckt:

Die gute Nachricht (mit vielen Wenns und Abers):
Telefonhörer D i r e k t a n s c h l u ß als Mikro über iMic Audio In geht gut. Bei Einsatz von iMic reagieren die Speakable Items auf Sprache durch den als Mikrofon benutzten Telefonhörer. iMic auf MIC stellen, nicht auf LINE. Beim Zusammenfriemeln der Adern kann eine Abschirmung des Audiokabels von iMic kommend für eine der Adern aus dem Telefonhörer als Leiter dienen. Der Anschluß beider Audio-Adern an beide Telefonadern lieferte jedenfalls bei mir nichts für Flo's Konzept Verwertbares.

Von Interessierten zu prüfende Handicaps:
1. Ob das Gleiche mit den von Apple in Macs verbauten Audio In Buchsen auch geht, kann ich nicht beurteilen, würde mich aber nicht wundern, wenn es da Schwierigkeiten gibt.

2. Reicht der Signal-Rauschabstand und die Sprachqualität aus der altertümlichen Mikrokapsel des jeweiligen individuellen Telefonhörers, um mit Speakable Items sicher genug ein Audiofile zu starten? Alternative: Telefonkapsel aus der Sprechmuschel raus, altes Apple Mikro rein.

3. Für welche irgendwas in die Muschel Nuschelnden müßte Speakable Items dann eingestellt werden? Reicht "Hallo", "Hello-o", "Alloo", "PRonto" oder "¡FUCK" (australisch)? Welche der Aussprachen von Chinesisch ist gerade angesagt?

4. Es wäre besser, wenn:
a) - die Verbindung Von Hörermuschel zu Audio In so funktioniert, daß der Audio Input mit der Hörergabel an und ausgeschaltet wird, damit Speakable Items Geräusche aus der Umwelt nicht irrtümlich als Befehle interpretiert. Zwischen Hörermuschel und Audio In liegt in diesem Fall aber noch die Platine mit der Hörergabel. Das scheint, zumindest in meinem Versuchsaufbau, eine Barriere zu sein, die Saft vom AudioIn-Leiter und Signale von der Hörermuschel nicht ohne weiteres durchläßt. Mit meinem paar Krokodilklemmen läßt sich das jetzt nicht weiter klären.
b) - sich Speakable Items dann auf eine Art Universal-Laut einstellen läßt. - So nach dem Motto: Hauptsache ich hör' irgendwas, dann geb' ich den Impuls ein Soundfile abzuspielen ...

5. Wenn aber Speakable Items nur gebraucht wird, einen irgendwie gearteten Sound als Signal zu nehmen: In vielen Fällen wäre es einfacher, das direkt über die Hörergabel ausgelöste Knacken oder Brummen auszuwerten. Es muß doch mit einfacheren Programme und Funktionen als SI möglich sein, Signale zu verwerten um das Abspielen eines Soundfiles zu starten. Oder?

kodjo kurzschluß