Beiträge von sparkie

  • Welche USB Soundkarte kann >4V am Mic Eingang?

    was soll eine hoehere Spannung fuer die Phantomspeisung bringen? Das Micro ist so hochohmig, da faellt selbst bei groesseren Leitungslaengen kaum Spannung auf der Leitung ab. Aber der Brumm wird durch die grossen Leitungslaengen natuerlich beguenstigt. Insbesondere weil das Micro so hochohmig ist. Deswegen mit dem RPi naeher an das Micro gehen.

  • DoorPi zur Auslösung von Schaltvorgängen per DTMF an entfernten Servern

    die Frage ist: wie sollen die DTMF Toene ueberhaupt 'abgespielt' werden?


    Soll das der DoorPi selber tun oder soll es ueber den Mikrofoneingang und per Dialer (z.B. Smartphone Applikation) geschehen?


    linphone unterstuetzt keine DTMF Erkennung. Zumindest habe ich das nicht hinbekommen. Deswegen uebernimmt diese Aufgabe mein nachgeschalteter Asterisk (ueber die 'SIPDtmfMode(inband) Funktion). Auf diese Weise kann ich bei bestehender Sprachverbindung per Dialer beliebige DTMF Sequenzen einspeisen, die dann von meinem System entsprechend ausgewertet werden.

  • Echo Problematik

    eine Bauanleitung habe ich nicht verfasst, da sich bei mir die Tuersprechanlage ueber mehrere Rechner erstreckt. Das linphone steht z.B. mit einem Asterisk im lokalen Netzwerk in Kontakt. Da linphone keine DTMF Erkennung (ueber das Mikrofon) beherrscht. Diese Funktion uebernimmt der Asterisk.
    DTMF Eingabe per Smartphone App ist wichtig wenn ich z.B. ueber das Internet nicht mehr an die Sprechanlage komme. Im Notfall kann ich so ueber DTMF trotzdem alle wichtigen Kommandos an die Anlage geben. Z.B. wenn ich unten vor verschlossener Haustuere stehe und bei Internetausfall trotzdem ins Haus moechte :)


    dieses Thema ist aber etwas OT hier...

  • Echo Problematik

    Zitat von accuvue

    @sparkie
    Hälst Du und über Deine Versuche mit dem Raspberry-Software-Echocancaller auf dem Laufenden? Das AEC-Modul scheint ja wegen der nicht vorhandenen Rechnerkapazitäten im Raspberry aus dem Projekt entfernt worden zu sein?

    welches Projekt meinst du? DoorPI oder Raspbian?


    Ich kann nur sagen der Echo Canceller ist auf einem *unverfaelschten* Raspbian in der CLI Version 'linphonec' sowie in der GUI Version 'linphone' vorhanden. Er funktioniert definitiv sehr gut auf einem RPi B 3. Dort wird ein ansonsten deutlich hoerbares Echo wirksam unterdrueckt. Kann man jederzeit durch (De)aktivieren der Funktion reproduzieren.


    Ich nutze so ein System produktiv fuer den Tuersprechbetrieb in einer groesseren ELCOM Anlage: doorpi-im-elcom-hager-i2bus-i2audio-netz. Das System ist jedoch rein Raspbian basierend (also kein DoorPI). Deswegen kann ich zu DoorPI nichts sagen.


    Sogar auf einem RPi B 1 kann der Canceller aktiviert werden. Hier habe jedoch noch keine Tests zur Wirksamkeit der Echo Unterdrueckung gemacht, da auf meinem Test RPi B 1 derzeit gar kein Echo entsteht und deswegen auch nicht unterdrueckt werden muss. Das Aktivieren der Funktion stoert aber selbst auf dem RPi B 1 den normalen Betrieb schon mal nicht.

  • Echo Problematik

    Zitat von stonev

    Nein, bei Linphone gibt es keine Stellschrauben dafür. Die für den Raspberry genutzte Versieon "Linphone for Raspberry" ist genau in diesen rechenintensiven Bereichen abgespeckt. Deswegen gibt es auch keine anderen Sprachprotokolle wie Speex o. ä.
    Hatte icheine Seite zuvorauch schon geschrieben.

    diese Feststellung mag vielleicht fuer die von DoorPi verwendete Version von 'linphone' gelten. Das kann ich nicht beurteilen, da ich kein DoorPi verwende.


    Das im Standard-Raspbian vorhandene 'linphone' hat jedoch den 'echo cancel' und Speex u.a. sehr wohl implementiert.


    Dieser Echo Canceller ist sogar auf dem ersten Raspberry Pi 1 Model B grundsaetzlich lauffaehig und funktioniert. Damit teste ich gerade.


    Nach Gespraechsende gibt es eine Statistik mit Usage Statistik:


    warum DoorPi ausgerechnet eine Version von 'linphone' nutzt, die mit 'echo cancel' solche Probleme hat verstehe ich nicht, da es sich schliesslich um eine fuer Tuersprechanlagen essentielle Funktion handelt.

  • Echo Problematik

    der echo canceller des linphone ist recht lustig. Manchmal bringt er die Meldung:

    Code
    -------auto answering to call-------
Connected.
linphonec> Call 12 with <sip:ip1@192.168.144.214> connected.
Media streams established with <sip:ip1@192.168.144.214> for call 12 (audio).
warning: The echo canceller started acting funny and got slapped (reset). It swears it will behave now.


    :)

  • Echo Problematik

    emilio20:


    sorry, ich verwende keinen Doorpi sondern ich habe mir auf Basis eines minimalen Raspbian (entspricht debian-stretch) sowas aehnliches wie einen Doorpi gebaut. Ich denke aber die gewonnenen Erkenntnisse koennten auch fuer Doorpi nuetzlich sein. Deswegen habe ich sie hier gepostet.


    Was habe ich gemacht?


    Zur Hardware:
    - Raspberry Pi 3 Model B+
    - Sabrent USB Externe Soundkarte (ASIN B00IRVQ0F8) (fuer 6.99€ bei einem grossen Online Versandhaus)


    Zur Software:
    - minimales Raspbian mit ssh Zugang (installiert mit Debootstrap)
    - linphone zum Testen in der Vollversion. Installiert mit:

    Code
    apt get linphone

    - keine nenneswerten pulseaudio Komponenten:

    Code
    # dpkg -l | grep pulse
ii  libpulse0:armhf                 10.0-1+deb9u1                     armhf        PulseAudio client libraries


    Damit ich die Grafikausgabe des 'linphone' auf meinem Desktop-Rechner sehen kann, logge ich von dort mit X11 forwarding auf meinem RPi ein:

    Code
    # ssh -X <rpi-IP>

    die einzigen relevanten Einstellungen/Kontrollen die ich nun in der GUI vom 'linphone' gemacht habe sind:
    - Kontrolle ob in den Multimedia Settings 'echo cancel' aktiviert ist
    - ob von linphone die richtige Soundhardware genutzt wird (heisst sinnigerweise USB Audio Device)
    - ob in linphone nur Codec PCMA aktiviert ist


    siehe auch Screenshots:




    die ~/.linphonerc schaut dann so aus (umbenannt, da dies sonst der Forumsupload nicht akzeptiert):


    linphonerc.txt


    diese Konfiguration sollte aber auch das linphone in CLI Version verstehen

  • Echo Problematik

    ich habe jetzt auf einem standard Raspbian mit RPI 3 B+ linphone getestet. Pulseaudio habe ich erst mal weggelassen.


    In der GUI von linphone erscheint unter 'multimedia settings' ein Button fuer 'echo cancel on/off'. Der funktioniert definitiv. Weil zusammen mit einer uralt Siedle TLE 051-02 hoere ich ohne aktiviertes echo-cancel mein eigenes Echo, das vom Tuer-Lautsprecher ins Tuer-Micro der TLE einkoppelt, sehr deutlich.


    Nach Aktivieren des echo-cancel im linphone ist dieses Echo reproduzierbar nach ein paar gesprochenen Silben komplett weg. Oft hoert man es von Anfang an nicht mehr. Natuerlich muss man dazu das laufende Gespraech (noch mit Echo) erst auflegen und ein neues starten, damit die Option aktiv wird. Das Echo ist sofort wieder da, wenn ich die Option deaktiviere.


    Deswegen verstehe ich nicht, warum hier zum Teil zu lesen ist, dass der echo-cancel vom linphone nicht funktionieren soll. Unter den obigen Bedingungen funktioniert es jedenfalls, rein softwarebasiert und ohne erkennbare Probleme.

  • DoorPi im Elcom/Hager i2bus i2audio Netz?

    der Thread ist zwar schon ein bisschen alt, ich weiss. Aber das Thema passt


    Mir ist inzwischen gelungen eine Ankopplung Raspi <-> ELCOM I2-Bus 2Draht System herzustellen.


    Hierzu habe ich ein billiges ELCOM REK241Y (elcom.fon Innenstation Audio mit Hörer) gekauft (ca. 42€) und zerlegt. Die REK241Y dient im Folgenden nur als Interface zwischen dem proprietaeren ELCOM 2Draht Systemprotokoll (das uns gar nicht mehr zu interessieren braucht) und einfachen Audio- und Schaltsignalen.


    • mittels 2 Uebertragern (fuer Micro und Speaker) erfolgt die Audio Ankopplung (z.B. an eine Raspi Audio Karte). Ich selbst nutze hierzu aus historischen Gruenden statt einer Raspi-Soundcard noch eine Telegaertner TS4 a/b als Interface zum Asterisk. Fuer die elektrische Verbindung wird einfach der Hoerer ausgesteckt und gegen ein eigenes 4P4C Kabel (verbunden mit den Uebertragern) getauscht.
    • mittels 1 Reed Relais simuliere ich das Abnehmen/Auflegen des Hoerers. Hierzu muss der SMD Hall Sensor auf der REK241Y Platine entfernt werden. Stattdessen wird ein Pulldown Widerstand verloetet. Der eigentliche Gabel-Schaltkontakt erfolgt mit Reedrelais der Einfachheit halber auf der Platinenoberseite (siehe Bilder)
    • mittels 1 Reed Relais ueberuecke ich den Schaltkontakt des Tueroeffners (siehe Bilder)


    auf diese Weise stehen einem Raspberry alle wesentlichen Hardware- Funktionen einer ELCOM I2-Bus 2D Anlage zur Verfuegung (Tueroeffner, Gespraechsannahme/ Hoerer abnehmen, Gegensprechen, Hoerer auflegen), um in ein beliebiges ELCOM I2-Bus 2D System integriert zu werden. Bei mir laeuft das Teil erfolgreich in einer groesseren Gemeinschaftsanlage zusammen mit einigen ELCOM BVF-510, BVF-540, BFT-510, etc..



    Falls Interesse besteht kann ich gerne genauere Infos geben.



    Platinenoberseite (Reedrelais links im Bild fuer Tueroeffnerkontakt. Reedrelais rechts im Bild fuer Gabelkontakt)




    Platinenunterseite (rot markiert links der entfernte SMD Hall Sensor ersetzt durch einen 10k Pulldown Widerstand, rechts die Verbindung zum Tueroeffner)


  • stonev´s DoorPi mit hardwarebasierter Echo Cancellation (AEC)

    Zitat

    Welch Kamera und Mikrofon wurde verwendet?

    also sorry, das steht doch wirklich genau in der detaillierten Projektbeschreibung, die oben verlinkt ist.



    Das Projekt - eine klasse Loesung fuer das leidige 'Echo' Problem - Gratulation!


    Ich habe mir vor Jahren auch einen Door-Pi gebaut (da gab es dieses Forum noch gar nicht). Audio leite ich voellig am Raspi vorbei (ueber eine Doorline TS4 a/b). Diese erledigt auch den Echo-Cancel. Die Sprechqualitaet ist in beiden Richtungen sehr gut.


    Aber deine voll-integrierte Loesung ist natuerlich deutlich eleganter:-)