Hm, interessant. Also ich halte es am zielführendsten, wenn ich an dieser Stelle weiter suche.
Kannst du mal kurz beschreiben, wie du deinen Test "außerhalb DoorPi" durchgeführt hast? Ich würde gern mal sehen, ob ich dann auch eine Verbesserung sehe. Wenn ja, liegt es irgendwo im DoorPi/Python API.
Wenn das klappt, ist die Doorpi-Lösung in eine andere Liga aufgerückt.
DAS sehe ich absolut genau so. Von daher würde ich sagen, natürlich können wir die Problemfindung an meinem konkreten Fall ansehen, aber man sollte es durchaus höher aufhängen- wie gesagt hat jeder mehr oder weniger große Probleme mit Echo, und das haben kaufbare Lösungen von der Stange nicht. Von daher, wenn wir eine allgemein funktionierende Lösung finden, steht DoorPi ganz anders da.
P.S.:Ich sehe mich bestätigt in der Vermutung, dass die spezielle Ursache hier die akustische Kopplung über die Frontplatte ist.
Ja schon, wobei es aber in meinem Fall so ist, dass weder das Mikro noch der Lautsprecher mit der Frontplatte verbunden sind- es scheint wohl eher mit dem geschlossenen Gehäuse zu tun zu haben.
Alles anzeigenSoo, das hat mir keine Ruhe gelassen. Und eigentlich ist es ganz einfach. Sowohl der Echo Canceller als auch der Limiter funktionieren NUR, wenn noise_gate aktiviert wurde! Bei dem Limiter steht es auch indirekt in der Doku:
"The echo limiter is an algorithm that consists in lowering the gain of the mic input when the speaker is talking. Combined with the noise gate (see next section) it gives good results when the echo canceller no more works, because of non linear distorsion (saturation) of the echo path."
http://www.linphone.org/techni…er/linphone/documentation
Ich habe im Test das Micro und den Lautsprecher auf passende Lautsterke eingestellt. Danach habe ich das Micro quasi direkt auf den Lautsprecher gerichtet, so dass ich mich im DECT Handset deutlich selbst gehört habe. Egal ob ich den Echo Canceller oder den Limiter nutze, beide funktionieren einwandfrei! beim Canceller muss ich schon ziemlich laut reinbrüllen um mich selbst zu hören. Beide Systeme habe ich mit den Default Werten getestet. Als angenehmer Nebeneffekt von noise_gate ist das Rauschen im Hörer auch weg
Das finde ich schon mal sehr sehr geil! Ich werde versuchen die Tage mich auch mal weiter mit dem Thema zu beschäftigen und auch die genannten Tests durchzuführen. Kann aber etwas dauern, meine Familie will mich auch ab und zu mal außerhalb des Bastelkellers sehen 
Was ich am Wochenende mal noch gemacht habe ( motom001_new), ich habe mir mal angeschaut wo DoorPi eigentlich die Einstellungen vornimmt. Dies scheint ja in der Datei from_linphone.py zu passieren. Dort gibt es folgende Zeile:
self.core.echo_cancellation_enabled = conf.get_bool(SIPPHONE_SECTION, 'echo_cancellation_enabled', False)Ich habe jetzt einfach mal darunter folgendes eingefügt entsprechender der LinPhone API:
self.core.echo_limiter_enabled = TrueDas scheint auch irgendwas zu tun, leider nicht funktional. Also sprich, am Problem ändert sich nichts. Ich sehe im DoorPi Log folgende Fehlermeldung:
cannot set echo limiter to mode [1] because no volume send
cannot set noise gate mode to [1] because no volume sendDas bringt mich zu zwei Schlußfolgerungen:
1. Das Noise Gate scheint irgendwie standardmäßig aktiv zu sein
2. Irgendwie schafft er es nicht, den Limiter einzuschalten. Google macht mich hier irgendwie auch nicht schlauer
Daher: Wie könnte man heraus finden, ob die LinPhone-Lib, wenn über die Python API angesprochen, auch das Config-File mit den Settings einliest? Laut @AndyGR42 scheint der Limiter ja funktional zu sein, also irgendein Problem gibt es da noch.
Und: Wie kann man LinPhone dazu bringen, mehr Logs zu generieren? Ich denke LinPhone hat alles an Bord was benötigt ist, man muss jetzt "nur" noch rausfinden, warum es innerhalb DoorPi nicht funktioniert...
Ich kann mir in meinem Fall nicht vorstellen, dass das ein von außen erzeugtes Problem ist. Auch nicht irgendwie zufällig. Ich kann ja eindeutig reproduzieren, dass es ohne Frontplatte "noch ok" ist, und mit nicht. Vermutlich war das während meiner Teststellung schon immer so, da war ja nie eine Frontplatte drauf.
Das Thema Echo cancellation halte ich persönlich eigentlich für aktuell eins der wichtigsten Themen in DoorPi überhaupt. Nicht, weil das jetzt genau mein Problem ist, sondern weil das die "eigentliche" Funktionalität des Gegensprechens betrifft. Überspitzt gesagt, was nützt mir eine Einbindung ins Smarthome, RFID Zugangsregelung und dergleichen, wenn die Basisfunktionalität nicht ok ist...
Soweit ich das bisher sehen kann, hat eigentlich jeder der DoorPi nutzt ein Echo, die einen mehr die anderen weniger. In meinem Fall ist es so dass ich überhaupt nicht zu einem produktiven Einsatz kommen kann. Von daher finde ich muss man das Thema Echo cancellation als möglichen Ansatz stärker verfolgen. Es gab ja mal Bestrebungen in die Richtung, die aber irgendwie alle im Sand verlaufen sind.
Ich würde natürlich gerne was dazu beitragen, aber ich verstehe aktuell überhaupt nicht, wo ich ansetzen kann. liblinphone hat scheinbar umfangreiche Settings dazu. Aber in allem was Google findet ist von irgendwelchen Config-Files die Rede, die ich bei mir nicht finde. Wie nutzt DoorPi denn LinPhone? Wie könnte ich an den Echo Cancellation Settings spielen? An und Aus scheint ja irgendwie über die Doorpi-Ini möglich zu sein. Wenn ich genauere Infos hätte was ich tun könnte, mache ich das gerne... auch das Thema Traces/Fehlerberichte wäre wie @AndyGR42 sagt natürlich hilfreich.
// edit: Ich habe gerade das hier gefunden, Auszug:
ZitatEcho limiter
The echo limiter is a liblinphone algorithm to clear out echo with a brute force method. It consists in cutting down the microphone signal when active signal is played by the speaker/receiver, to prevent voice to feed back into the microphone. This algorithm has disadvantages compared to the hardware or software echo cancellers because the remote user will be not hear any background noise when speaking, which is confusing. As a result the echo limiter method shall be used only under situation where echo canceller can't perform, that is loud signals with heavy saturations, which usually happens when using the device in speaker mode. Echo limiter can be enabled or disabled during a call with LinphoneCall.enableEchoLimiter().
Das halte ich eigentlich für keine dumme Idee. Es bedeutet im Endeffekt, dass auf eine Art Half-Duplex Mode geschaltet wird. Wenn der Speaker ausgibt, wird das Mikrofon Level heruntergefahren. Das bedeutet zwar, dass während die Innenstelle spricht, der außen stehende nichts sagen kann, aber wir reden hier ja von einer Gegensprechanlage und wollen darüber keine großen Diskussionen führen. Kann man diese Option irgendwie einschalten? Ich würde das gerne probieren. Theoretisch müsste das zu einem sehr guten Ergebnis führen, mit der genannten Einschränkung
So, ich habe jetzt noch mal umfangreich experimentiert:
- andere Soundkarte
- anderes Mikrofon
- andere Kabelführung
- andere Anordnung der Komponenten
- Dämmung
Nichts davon hat eine brauchbare Lösung ergeben. Aktuell bin ich auf dem Stand, dass das Echo dann unerträglich ist, wenn Lautsprecher und Mikro eingebaut sind und die Frontplatte drauf sitzt. Nehme ich die Frontplatte ab, oder lasse sie drauf und führe das Mikro nach außen, dann ist das Echo zwar immer noch da und störend, aber im Hintergrund. Sobald das Mikro irgendwie auch unter der Front ist (sei es fest verbaut, lose hineingelegt, oder auf einem Stück Schaumstoff gebettet), ist das Echo lauter als die eigene Sprache.
Hat noch jemand eine Idee? Ich bin aktuell ganz kurz davor das Ding aus dem Fenster zu schmeißen und das Projekt für mich als gescheitert zu erklären- habe keine Ideen mehr.
Hast Du nicht, zumindest nicht mir.
Mir auch nicht, keine Sorge 
Ich werde eine solche Ausbaustufe im Auge behalten, aber mich wieder mehr auf die Grundfunktionen fokusieren.
Das halte ich für eine sehr gute Idee. Meiner Meinung nach ist DoorPi das einzige verfügbare (Open-Source) Projekt, dass wirklich Potential hat im Türsprechanlagen Bereich. Dennoch - und das meine ich nicht als Kritik - hat es noch einige Schwächen, und die sollten zuerst verbessert werden, bevor man immer mehr Funktionalität rein packt. Ich entwickle seit vielen Jahren beruflich Software, und ich habe schon einige Projekte den Bach runter gehen sehen, weil man sich nicht auf den Kern konzentriert hat, sondern immer mehr Funktionalität rein gepackt hat, die dann nur halbherzig funktioniert (das angesprochene Thema Ressourcen ist da natürlich ein Hauptthema). Deswegen gehen da bei mir alle Alarmglocken an
Ich möchte auch keine DoorPi Installationsanleitung die beginnt mit "installiere FHEM".
Falls es so rüber gekommen ist, dass ich sowas favorisieren würde, dann ist das ein komplettes Missverständnis. Im Gegenteil, es sollte eine klar definierte Schnittstelle zwischen beiden System geben, und ansonsten beide System völlig autark sein.
Wenn es jemanden gibt, der eine Verbindung herstellt bin ich sehr froh und werde versuche das aktuell und in Zukunft zu unterstützen. Aber Zwang soll das nicht werden.
Das mit dem Zwang sehe ich genauso, siehe oben. Es sollte die Schnittstelle geben, und ob das jemand nutzt oder nicht ist jedem selbst überlassen. Genauso sollte es aber generell sein- auch das Client-Server Thema sollte optional sein, eine prinzipielle Umstellung auf Client-Server halte ich für falsch.
@Nea:
Im Prinzip haben wir doch ungefähr das gleiche gesagt oder? Ich schrieb ja auch, dass ich die Server-Client Lösung eine gute Idee finde (optional natürlich). Ich schrieb nur, dass man nicht zu viel Funktionalität hinein packen sollte- die Beispiele die @motom001 zuletzt genannt hat, sind im Grunde genau die von dir angesprochenen "Spielereien" (Garage öffnen, Licht einschalten).
Ob man sowas "braucht" oder nicht, muss jeder selbst entscheiden. Ich bin nur der Meinung das sowas nichts in DoorPi verloren hat, denn genau diese Dinge können andere Systeme (FHEM ist nur ein Beispiel) besser.
Ich halte es einfach für eine schlechte Idee, aus dem DoorPi Projekt jetzt eine universelle Steuerzentrale für allerlei Sensorik zu machen.
So könnte man z.B. durch einen iButton oder RFID-Tag am Gartenzaun die Garage öffnen, das Licht am Hauseingang einschalten und die Rufumleitung für die Klingel von Handy auf Festnetz umstellen.
Was Du in Deinem Post an Wal beschreibst ist quasi dass gleiche, was diverse Smart Home Systeme machen. Warum also hier das Rad neu erfinden, wenn es FHEM gibt?
Das sehe ich auch so. Ich mag die von dir ( motom001_new) beschriebenen Szenarien, aber ich halte es falsch zu viel über den DoorPi laufen zu lassen. FHEM kann das alles und noch viel mehr- ich halte es für sehr viel sinnvoller, dass der DoorPi für solche Szenarien bestimmte Events einfach an FHEM schickt, und dort wird entschieden, was passieren soll. Warum?
Erstens, weil es das alles schon gibt und es somit unnötige Zeit ist, sowas in DoorPi nochmal zu implementieren.
Zweitens, weil es DoorPi sehr viel komplexer macht als es jetzt ist, und es ist jetzt schon nicht gerade trivial.
Und Drittens, weil die von dir beschriebenen Szenarien nur der Anfang sind- spätestens wenn man sowas am laufen hat kommt man auf die Idee, dass man z.B. die Lautstärke des Fernsehers senken könnte, wenn er läuft und es klingelt. Oder dass automatisch eine Rufeinleitung eingerichtet wird, wenn niemand mehr im Haus ist. Oder dass noch irgendwelche anderen Lichter ein- oder ausgeschaltet werden sollen, wenn es klingelt. Geht in FHEM alles, in DoorPi nur ein Teil davon. Und dann hat man einen Teil im einen System realisiert und den Rest im anderen- unschön und unübersichtlich.
Meine Meinung ist, DoorPi sollte sich auf Funktionalitäten beschränken, die direkt mit dem Gegensprechen und dem Öffnen der Tür zu tun haben. Weitere intelligente Funktionalität können mit anderen Systeme sinnvoller realisiert werden.
Was nicht heißen soll, dass ich generell gegen die Client-Server Lösung bin. Das kann man sicher machen und es macht für bestimmte Sachen auch Sinn, aber welche das sind sollte man gut überlegen.
Ja, wie ich schrieb, das passt ja dann. Du wirst ja vermutlich die USB Soundkarte nutzen und die ist Index 1.
Und was hast du jetzt in DoorPi als capture_device und als playback_device eingetragen? Ich vermute dort ist nicht die USB Soundkarte eingetragen oder nicht richtig.
Technisch gesehen, wird jedes Event von Anfang bis Ende durch ein einzigen Thread verarbeitet. Das feuern eines zweiten Events jedoch ein anderer Thread...
Ok, verstanden soweit. Das würde nach meinem Verständnis den Wunsch von @pahenning (den ich für sehr gut und wichtig halte) erfüllen.
Generell finde ich den Vorschlag von dir mit der Aktion für das Feuern eines Events sehr gut, aus folgenden Gründen:
1. die von dir beschriebene Funktionsweise der Event-Abarbeitung: "Ein Thread pro Event, innerhalb eines Events alles seriell" ist einfach, und daher leicht zu verstehen. Wenn man jetzt etwas einführen würde, was dann durch eine bestimmte Syntax oder eine bestimmte Aktion innerhalb eines Events zu Parallelität führt (ohne dass man das sieht), wird es bei komplexen Aktionsfolgen schnell sehr unübersichtlich.
2. Wenn man selbst Events feuern kann, kann man sich viel Schreibarbeit ersparen und auch die Wartbarkeit (des ini-Files) erhöhen. Beispiel: Ich habe in meinem System mehrere Events, die den Türsummer auslösen sollen (DTMF-#, virtuelle Taste, mehrere unterschiedliche RFID-Tags). Daher habe ich jetzt mehrere Events, wo überall die (gleiche) Aktionsfolge für das Türöffnen drin steht. Wenn ich mal die Betätigungsdauer oder sonst etwas an der Folge ändern möchte, muss ich schauen dass ich es an allen Stellen ändere. Mit der FireEvent Aktion könnte man einfach an allen Events die den Türsummer betätigen sollen ein "FireEvent:openDoor" eintragen, und nur noch an einer Stelle (beim EVENT_openDoor) die "eigentliche" Aktionsfolge.
Sieht eigentlich soweit gut aus, nur dass Mic Playback Switch auf off und Mic Playback Volume auf 0 stehen sollten.
Da fällt mir gerade noch ein, ist das die richtige Soundkarte?
Gib zur Sicherheit mal
cat /proc/asound/cardsein.
Wenn die richtige Karte als Nummer 1 auftaucht, sind die obigen Angaben richtig und du musst nur das Mic Playback noch einstellen (erklärt aber irgendwie nicht, warum du nichts hörst - aber die ALSA Settings passen dann schon mal).
Wenn sie nicht als Nummer 1 auftaucht, dann obigen Befehl aus dem letzten Post entsprechend mit -c2, -c3 oder der richtigen Nummer eben wiederholen.
Mach mal ein
sudo amixer -c1 contentsund poste den output.
Wie arbeitet denn die sleep Aktion? Ist während die Sleep Zeit läuft das Event System blockiert oder können währenddessen weitere Events verarbeitet werden?
Der Sinn von deinem Vorschlag ist mir nicht klar (hängt von der Antwort auf die Frage ab), was wäre der Unterschied zu:
[EVENT_OnKeyPressed]
10 = out:lighton,1
20 = sleep :30
30 = out:lighton,0?
Für Elektretkapseln gibt es solche Halterungen: Klick (Beispiel)
In genau so einer sitzt die Kapsel bei mir. Also die ist ringsum von Gummi umgeben, nach hinten habe ich die Halterung mit einem Tropfen Heißkleber verschlossen, das fixiert auch noch das Kabel ganz gut. Eigentlich dachte ich dass ich damit ganz gut aufgestellt sein sollte, was Entkopplung und Dämmung angeht 
Auch mein Lautsprecher hat schon eine Neoprendichtung, die ist da ab Werk dran...
Akustische Signale dämpft man am besten mit Masse. Leichte Materialien sind da eher ungeeignet.
Ok, hast du da eine konkrete Idee was man nehmen könnte?
//edit: habe ich geschrieben bevor ich den Post von Nea gelesen habe. Also Butyl z.B.?
das Micro so weit wie möglich vom Lautspreche einbauen und gut wie möglich von innen dämpfen.
Ja, prinzipiell habe ich an den Abstand auch gedacht. Die Kamera sitzt so weit oben wie es geht. Einen weiteren Abstand könnte ich nur erreichen, wenn ich Mikro und Klingeltaster vertausche, das wäre aber leider nicht gegangen aus Platzgründe (Stichwort Tiefe des Tasters und restliche Komponenten die dahinter liegen).
Bei deiner Sprechstelle ist das Micro ja quasi frei im Gehäuse der Sprechstelle angebracht. Die Plexiglas verschließt das Gehäuse auch ohne Frontplatte. Das ist wie ein Lautsprechergehäuse. Außerdem sind Lautsprecher und Micro an der gleichen Platte befestigt. Darüber kann sich Schall prima übertragen.
Da hast du recht. Es wird zwar nicht vollständig verschlossen, da Kamera und Taster auf der Frontplatte sitzen und die Aussparungen dafür in der Halteplatte um einiges größer sind, aber prinzipiell stimmt es.
Allerdings- wie kann man das umgehen? Wenn es nicht durch die Halteplatte verschlossen wird, dann durch die Frontplatte. Auch die Anbringung an der gleichen Platte zu vermeiden erscheint mir schwierig.
Könnte es vielleicht was bringen, um den Lautsprecher hinten herum eine extra "Box" zu setzen? Das würde bei mir allerdings auch schwierig, denn da komme ich mir mit dem Ethernet-Kabel in die Quere...
Ich würde das Micro mal testweise vor die Platte herausführen. Einfach um mal zu sehen was dann passiert.
Ok, das werde ich testen.
Danke für deine Antworten, sehr hilfreich!
Danke, verstanden.
Habe jetzt noch mal mit Styropor und Schaumstoff versucht irgendeine Verbesserung herbei zu führen, ohne Erfolg. Außerdem habe ich noch versucht pulseaudio zum Laufen zu bekommen, was auch eine Echo cancellation hat. Aber das habe ich bisher nicht geschafft.
Abschwächen lässt sich das Problem indem man die Empfindlichkeit vom Mikro bzw. die Lautstärke vom Lautsprecher runter setzt, aber auch dann ist es nicht zufrieden stellend.
Also im Moment gehen mir die Ideen aus. Benutzen kann ich das so definitiv nicht.
Ein Echo habe ich nur auf der Seite der Türstation - die Lautsprecher sind zu nah am Mikrofon. Das geht aber gerade noch, die Mikrofonkapseln sind gut gepolstert.
Moment, langsam. Das meinst du so, dass das Echo an der Türstation (=Außeneinheit) erzeugt wird, und du hörst es am Telefon (=Inneneinheit) - richtig? Anders herum wäre das nicht logisch, oder benutzt du an der Inneneinheit auch freisprechen?
Und wieso "die Lautsprecher" bzw. "die Mikrofonkapseln"? Hast du da mehrere 
Und mit was sind diese gepolstert?
Insofern kann es natürlich an der Frontplatte liegen, die eine akustische Kopplung herstellt.
Das dachte ich auch, aber ich schrieb ja oben dass ich es immer noch da ist, wenn ich die Frontplatte wieder abnehme. Lautsprecher und Mikrofon sind nicht mit der Frontplatte verbunden sondern sitzen auf einer Platte darunter- sind also insofern schon über diese Platte verbunden, aber auch das war schon immer so...
Da könnte man eine kleine AluButyl oder nur Butyl Matte zurechtschneiden und einkleben, evtl noch den Lautsprecher und die Kapsel mit Schaumstoff hinten auskleiden.
Ja ich habe gestern schon mal ein wenig mit Styropor hantiert, aber bisher ohne Erfolg.
Sonst ist niemand echogeplagt
Nein
Es sind keine Abstände und keine Kabelführungen verändert worden. Es ist jetzt eine Frontplatte drauf- ich habe schon darüber nachgedacht, aber finde nicht so recht eine Begründung warum das das Echo verstärken sollte (zumal sie nicht aus Metall ist). Natürlich habe ich sie auch mal wieder abgenommen und stellte aber keinen Unterschied fest. Und es sind neuerdings noch Beleuchtungs-LEDs an 5V angeschlossen, das Problem ist aber auch vorhanden, wenn diese aus sind.
Eine einzige Sache ist mir heute vormittag eingefallen die ich geändert habe: Der Pi bekommt seinen Strom nicht mehr über Micro-USB, sondern wird über Schraubklemmen versorgt, die auf dem PiFace liegen. Das Netzteil ist das gleiche. Da sehe ich zwar auch noch nicht inwiefern das ein Echo verursachen sollte, aber das werde ich noch mal rückbauen um es auszuschließen.
Die anderen Komponenten (RFID-Reader, Verstärker) bekommen ihren Strom nach wie direkt vom Netzteil, wie vorher auch.
Ansonsten- nein, es wurde an der Hardware wirklich nichts geändert.
Mich würde mal interessieren ob es generell Leute gibt die keinerlei Echo haben oder ob es einfach klein genug ist.
Hi
ich mache der Übersichtlichkeit halber mal einen neuen Thread zum Thema "Echo" auf.
Es gab hier und hier schon mal Diskussionen dazu. Die Hardwarelösung möchte ich nicht, da ja einige scheinbar ein produktives System ohne Echo-Probleme haben.
Ich hatte anfangs "erträgliche" Echo-Probleme, aber aus irgendeinem Grund dem ich noch nicht auf die Schliche gekommen bin, habe ich jetzt ein riesiges Echo. Teilweise so laut dass man nicht mehr normal sprechen kann, also mein DoorPi ist aktuell unbenutzbar
Mich interessiert daher folgendes von allen die ein DoorPi System produktiv am Laufen haben:
- Habt ihr gar keine Echo-Probleme oder ist das Echo einfach erträglich?
- Habt ihr irgendwelche Maßnahmen bzgl Echovermeidung/Unterdrückung getroffen?
- Wenn jemand ein komplett echofreies System hat würde mich interessieren welche Audio-Hardware verwendet wird (Cirrus Card ausgenommen...)
Hat jemand eine Idee wo ich den Fehler suchen könnte? Es muss ja einen Grund geben dass es bei mir stärker geworden ist. Am prinzipiellen Aufbau (Verkabelung etc) habe ich nichts geändert. Könnte eine andere Soundkarte eine Verbesserung bringen? Oder sonst eine Hardware-Änderung?
Kann ich softwareseitig irgendwas verändern?
Joker: Noch nicht das Video angesehen ?
Doch- warum?
Ok, scheint ja doch einige Lieferanten zu geben. Da ich es nicht eilig habe warte ich erstmal noch.
Edit: was mir gerade noch einfällt- gibt es schon Erfahrungswerte mit direkter Sonneneinstrahlung? Sind die Displays dann immer noch lesbar?
Gut zu wissen, hat jemand mal eine unkomplizierte Bezugsquelle für solche Stecker?
Für Testzwecke könnte ich auch solche Stecker die man direkt auf CAT7 anbringen kann brauchen. Ich dachte immer da gibt's nix...
