Beiträge von stonev

    In Pulseaudio gibt es den "Adrian Echo Canceller"
    Anscheinend sollte es möglich sein diesen zwischen Alsa und linphone zu schalten.
    In diesem Thread ist es aber zu keiner endgültigen Lösung gekommen.


    Link: http://www.forum-raspberrypi.d…von-adrian-echo-canceller

    Erlaubt mir die Anmerkung, dass ihr euch hier imho ziemlich im Kreis dreht. Das Thema, es über Pulseaudio zu lösen hatten wir schon. Ich habe es mangels Kenntnisse leider auch mit Hilfe aus dem von dir verlinkten Forum nicht hinbekommen. Aber vielleicht könnte BooosesThaSnipper mit seinen Linuxkenntnissen hier aushelfen und diesen Ansatz weiter verfolgen?


    Welche Möglichkeiten gibt es denn, das Echo loszuwerden?


    • akkustische Entkopplung:
      Wird hier gerne ins Feld geführt. Ist auch sicher etwas dran. Aber mal ehrlich: Ich werde damit nie verhindern, dass es im Vollduplex zum Echo kommt. Ich kann damit ein wenig optimieren, aber nie das Problem lösen.
    • softwareseitige Echo cancellation
      Der in DoorPI verwendete SIP Client linphone for Phyton unterstützt kein AEC! Ich weiß nicht ob es updates dieses Clients vom Hersteller gibt, wodurch sich das ganze inzwischen geändert haben könnte. Fakt ist aber: Mit dem eingebauten VOIP Client geht es nicht (auch wenn in den Einstellungen eine Option dafür da ist). Grund ist wohl die Rechenleistung des PI, wie in der Doku zu lesen ist:

      Code
      Other interesting things to note are that:
      the echo canceller is disabled because it uses a lot of CPU power which the Raspberry PI does not have. And it is not really useful for that use case.
      the only audio codecs enabled are PCMU and PCMA for the same reason. Other codecs such as speex or opus require too much CPU if we want to also have the video.

      Alternativen:
      - Pulseaudio (s. o.)
      - anderer VOIP Client in DoorPI (genug Rechenleistung?)

    • hardwareseitiges AEC
      Ich hatte die Wolfson Audiocard probiert, welche zwar mit AEC beworben wird, aber wie sich später herausstellte, den entsprechenden Codec nicht implementiert hatte. Die war also unbrauchbar.


      Ich halte diese Variante für die sicherlich beste, nur habe ich bisher kein preiswertes Produkt gefunden. Harware die einfach plug&play in den analogen Audiostrang integrieren läßt, ist kaum zu finden. Ich habe nur dieses hier entdeckt: https://www.voiceinterconnect.de/vicCOM2.html


      Das kostet aber leider auch
      bis 50 Stk. 99,90 Euro netto
      ab 50 Stk. - 79,90
      ab 200 Stk. - 64,90
      ab 500 - 49,90
      ab 1000 - 37,90
      ab 5000 - 29,90
      ab 10000 - 24,90


    Eine preiswerte Hardwarelösung wäre sicherlich am besten. Letztlich steckt dieses Technik zwar in so vielen billigen Geräten drin, aber meist derart stark integriert (Rufannahmetasten etc.), dass sie nicht einfach zu mißbrauchen sind. Sollte hier jemand etwas finden, wäre dies m. E. der Durchbruch.


    Ansonsten geht es wirklich preiswert imho nur über eine Softwarelösung. (Sofern der RPI das mit seiner Rechenleistung schafft)
    Hier wäre Pulseaudio ggf. eine Möglichkeit. Eleganter wäre natürlich, in Doorpi einen VOIP Client zu integrieren, der das von Haus aus kann. Ob es eine passende Software gibt und ob das so einfach geht, kann ich allerdings nicht beurteilen.


    https://www.doorpi.org/forum/user/311-booosesthasnipper/

    Hi Wal,
    ich habe für den RPI B die gleiche Audio Card (nur in der älteren Version).


    Ich verzweifle gerade daran den Taster anzuschließen. Wie hast Du das gelöst? Wo an der Hardware angeschlossen, welcher GPIO und welcher PIN? Hast Du die Pin Bezeichnung des RPI (22 für z. B. GPIO25) oder die des EX Connectors der Audiocard (Pin 16 des Ex Connectors für GPIO25) in der Config des Doorpi verwendet?


    EDIT:
    Der letzte Versuch des Tages ist geglückt. Bei meiner Wolfson Audiocard für den RPI B habe ich Ex Conextor den PIN16 (Bezeichnung: "GPIO3") gewählt. Dieser entspricht GPIO25 und PIN22 am RPI. Pin22 ist dann auch für die Config des DoorPI maßgeblich.


    Da war das Manual des älteren Boards sehr schlecht. Erst das Manual zum neueren Cirrus Board gab Klarheit...

    Ich würde es an deiner Stelle zu dem Preis auch testen. Würde mich sehr interessieren. Wenn ich noch eatwas von Pollin bräuchte, würde ich es auch probieren. Mal sehen....


    Möglicherweise unterdrückt der verbaute "Soundchip" auch den Echo Effekt. Das wäre ein riesen Vorteil.
    Das einzige Risiko besteht wie schon oben gesagt darin, ob das Gerät mit den ALSA Treibern läuft.

    Noch eine software-Variante zur Vermeidung des Echos: Pulseaudio


    Gemäß diesem Artikel ist in Pulseaudio ein Modul eingebaut das sich "Adrian echo canceller" nennt.
    Ggf. wäre dies ja nutzbar.


    Ich versuche das gerade mal zu testen. Habe mit

    Code
    sudo apt-get install pulseaudio


    Pulseaudio installiert. Die Ausgabe von aplay -L sieht bei mir dann so aus:


    Als Capture und playbackdevice habe ich unter Doorpi dann "ALSA: default" eingestellt. Ton funktioniert, aber leider noch kein Effekt. Ich weiß aber absolut nicht, ob Audi jetzt auch tatsächlich über Pulseaudio läuft und falls ja, ob dort der Echo canceler auch aktiv wirkt.


    Hat da jemand eine Idee, wie das herauszufinden wäre? Kann man Pulseaudio noch irgendwo konfigurieren?
    Kann DoorPi grundsätzlich mit Pulseaudio kommunizieren?

    Nochmal zu o. a. Cirrus (ehemal Wolfson) Audio Card:


    Der Support für diese Karte seitens Cirrus ist wohl mehr als dürftig. Cirrus bietet ein fertiges Image für den RPI an, welches die Treiber für die Karte enthält. Dieses datiert allerdings auf 04.2015 und basiert vermutlich auf Noobs.


    Für alle die das Teil testen:
    Ich habe hier eine Seite mit einer Anleitung gefunden, nach der eine Installation (Patch des Kernels) unter Jessie möglich sein könnte (ungetestet):
    http://www.horus.com/~hias/cirrus-driver.html
    dazu gibt es dann auch einen Thread im Forum von elements14: https://www.element14.com/comm…s-to-kernel-31816-and-405



    Ist alles nicht sonderlich elegant, aber es ist das einzige Soundboard mit Mikrofoneingang, dass ich gefunden habe. Dazu mit echo cancellation...



    Allerdings: Wenn das System einmal stabil läuft, gibt es keinen Grund, daran ständig irgendwelche Updates vorzunehmen. Ich werde es wohl mal versuchen, allerdings die Version für einen RPI B.

    Nea:
    Ich wollte keinem von euch auf die Füße treten - Sorry. Mir ist bewußt, wie viel Engagement und Zeit von euch darin steckt.
    Mir ist auch bewußt, dass AVM hier der limitierende Faktor ist, den keine beeinflussen kann.


    War gestern ein Moment der Erleuchtung, als ich das erkannte und gleichzeitig großer Frustration.


    Welche Geräte nutzt ihr denn als Gegenstellen, auf die ihr dann ein Video streamt?
    Die Elcom App ist ja entwicklungstechnisch tot. sonst noch ne möglichkeit auf ein smartphone zu gehen. Oder Tablet an die Wand, oder läßt sich auch ein SIP-Bildtelefon verbinden? Letzteres bräuchte dann aber vermutlich nen VOIP Server als Gegenstelle.

    Habe heute die Cam installiert und sie nun unter RPi-Cam-Web-Interface am laufen.
    Die Fritz Box kann in Verbindung mit dem RPi-Cam-Web-Interface wohl nur ein einzelnes JPG auf (Live Bild) auf dem Telefon darstellen. Die Fritte soll nicht mehr können. Ist das ggf. in Verbindung mit dem mjpg-streamer anders?


    Funktioniert mit mjpg-streamer und Fritz Box auch eine Video Übertragung auf das Telefon?


    Ansonsten funzt RPi-Cam-Web-Interface ganz gut. Bei laufender SIP Verbindung und LIVE-Bild liegt die Prozessorlast eines RSP B (!) bei etwa 50%. Aber es wird ja auch kein Video gestreamt, weshalb ich die ganzen Bedenken bzgl. PI Performance, die ich gelesen habe nicht verstehen kann.


    Dachte eigentlich die Videoübertragung sei die Königsdisziplin. So eine schnöde Aussage: Die Firtz Box kann das nicht!", stellt mich nicht wirklich zufrieden. Da hätte ich dann eher auf eine a/b Gegensprechanlage an der Fritte gesetzt, die auch ohne die ganze Bastelei für kleines Geld funktioniert. Mit Bastelei, hätte mich dann ein Live-Video schon eher überzeugt.


    Wenn es mit DoorPi und Fritzbox nicht funtionieren sollte, wäre dann Asterisk und ein Grandstream SIP-Telefon als Innenstation nicht die bessere Variante?

    Bei mir läuft das RPI-Cam-Web-Interface nun soweit.


    Habe aber das Problem, dass auf dem Telefon bei eingehendem Anruf von der Außenstation nur ein einzelnes Bild angegezeigt wird und kein Videostream.


    Das Live-Bild habe ich in der Türsprechanlage der Fritte so eingetragen: <IP Raspi>:<Port>/cam.jpg


    Müsste ich da was andrers eintragen, oder kann das RPI-Cam-Web-Interface kein Livevideo an die Fritzbox streamen?


    Ok, wer kauft und testet :D


    Ha Ha, der is gut :D
    Ich werkel ja noch mit nem B Model. Nach Ostern kommt die Kamera und wenn das leistungsmäßig alles auf dem B läuft, ohne dass der einbricht, dann hol ich auch das Audiomodul dazu. Sollte ich auf Modell 2 wechseln müssen, wäre das rausgeworfenes Geld...

    In meinen Augen ist es keine Option, denn da steht dabei:


    Es gibt von dem Modul auch eine 2. Version für PI A+, B+, 2 und 3 :)


    Ich habe dann auch noch einmal etwas weiter in den Datenblättern gelesen. Drauf verbaut ist ein DSP Voice Processor (WM5102).
    Der kann u. a. folgendes:

    Code
    Programmable audio effects and voice processing functions
    - Transmit-path noise reduction and echo cancellation
    - Receive-path enhancement and noise reduction
    - Wind noise, sidetone and other programmable filters
    - Dynamic Range Control, Fully parametric EQs


    Das könnte gut angelegtes Geld sein...


    Mein Mikro hat etwa 10cm Kabellänge, wurde heute in Styropor gepackt und Empfindlichkeit bis kurz vor 0 runter geregelt. Trotzdem ein gruseliger Sound mit Echo :@

    Das grundsätzliche Problem des Echos ist hier beschrieben.



    Der effektiveste Weg, das Echo zu unterdrücken ist eine hardwareseitige Echo cancellation. Die softwarebasierten Lösungen funktionieren ganz oft wohl nicht zufriedenstellend. Bei Linphone für Phyton gibt es nur die oben angesprochene Funktion, die bei mir kaum nennenswerten Vorteile herbeiführt.


    Das Wiki von Linphone selber sagt dazu:


    Code
    The echo canceller is disabled because it uses a lot of CPU power which the Raspberry PI does not have. 
    And it is not really useful for that use case.
    the only audio codecs enabled are PCMU and PCMA for the same reason. 
    Other codecs such as speex or opus require too much CPU if we want to also have the video.



    Sieht also so aus, als kämen wir mit den vorhandenen Bordmitteln hier icht weiter. Ob pjsua bessere Softwarelösungen bereit ist die Frage, aber in jedem Fall dürfte auch diese an der CPU nagen.
    Ideal wäre ein Soundmodul für PI, der das hardwareseitig mitbringt. Aber gibt es sowas und ist es dann auch bezahlbar?
    Wäre das Teil von Wolf Audio ggf. eine Option? Im Datenblatt habe ich nichts zu echo cancellation gelesen, aber die werben mit "Aufbau eines VoIP - Konferenztelefons möglich".


    motom001_new:


    Zitat


    Kann jemand bitte das hier testen / validieren?
    https://lists.nongnu.org/archive/html/li...00024.html


    https://lists.nongnu.org/archi…ers/2015-07/msg00024.htmlWenn ich das richtig verstehe wird da nur der Audio Codec Speex besprochen. Da der von der Fritzbox aber nicht unterstützt wird, hilft das m. E. nich weiter.


    Zitat


    Kann jemand die aktuelle Version vom pjsua als Sipphone testen?


    Ich werde mich vlt. mal dran versuchen, allerdings könnte das meine Fähigkeiten übersteigen, pjsua in DoorPi einzubinden.

    Dank WAL konnte ich das interne Soundmodul des Pi deaktivieren. Bevor das aber in meinem Thread untergeht, hier nochmal für alle:


    1.
    Das Soundmodul wird in eine Blacklist gescrieben und somit mit dem nächsten Reboot nicht mehr geladen. Dazu folgende Datei neu anlegen:


    Code
    sudo nano /etc/modprobe.d/snd_bcm2835.conf


    ...und darin folgendes eintragen und speichern:

    Code
    blacklist snd_bcm2835



    2.
    Nun noch die USB Soundkarte zur Soundkarte 0 machen, damit ALSA auch was findet:

    Code
    sudo nano /etc/modprobe.d/alsa-base.conf


    ...und in dieser ggf. neu anzulegenden Datei folgenden Eintrag schreiben und speichern:

    Code
    options snd_usb_audio enable=1 index=0




    Dann Reboot und alles ist gut :cool:
    Danke an WAL


    Für den 2. Schritt gibt es laut Nea noch diese Möglichkeit, die selber aber noch nicht getestet habe.

    Ich habe die Funktion auch eingeschaltet. Es ist etwas besser (subjektiv), stellt mich aber nicht wirlklich zufrieden. Ich höre mich am Telefon immer noch stark selber reden.


    DoorPI bietet auch die Möglichkeit, den Codec einzustellen. Linphone bietet die Audio codecs: OPUS, SILK, SPEEX, G722, AMR-WB (G722.2), GSM 6.10, AMR-NB, ILBC, G729, G711
    In DoorPi ist PCMA,PCMU standard, was dem Codec G711 entsprechen müsste. Welche Möglichkeiten habe ich hier, mit dem Codec zu spielen und welche Werte müsste man eintragen? Di Fritbox unterstützt:

    • G.711a
    • G.711u
    • G.711 HD
    • G.722
    • G.726-24
    • G.726-32
    • G.726-40
    • iLBC 13.3
    • iLBC 15.2


    Der nächste Angriffspunkt wäre das Mikro. Ich habe eines genommen welches von einer VW Freisprechanlage noch hier lag. Vermutlich ein Mik mit Kugelcharakteristik. Entweder ich packe das Mik in Schalldämmendes Material (z. B. Styropor) so ein, dass es von hinten und von der Seite keinen Schall mehr empfängt (also vom LS), oder ein Mik mit Nierencharalkteristik (Superniere) könnte helfen. Da stehen noch Experimente an.


    Ich habe aber auch noch kein MIK mit Supernierencharakteristik gefunden, dass man problemlos verbauen könnte, wie die herkömmlichen Kapselmikrofone. Wer hier einen Tipp zur Hardware hat - her damit...

    Hast Recht, das ist stochern im Nebel. Vor allem weil es vorher ja auch funktionierte.
    Reinstalltion der alsa-utils hat übrigens auch nicht funktioniert. Nach dem Löschen funktionierte eine Neuinstalltion mit der blacklist nicht. Lies erst wieder installieren, nachdem ich die blacklist wieder gelöscht hatte.


    Ich steck da erst mal keine Energie mehr rein. Vielleicht ergibt sich später ja noch mal was.


    Wichtiger ist es, Mikrofon und LS akkustisch zu entkoppeln, um die Sprachqualität beim Gegensprechen zu erhöhen.
    Wirklich zufrieden stellt mich die Sprachqualität derzeit nicht... Muss da noch ein wenig experimentieren.


    Bietet linphone noch Möglichkeiten softwareseitig an der Sprachqualität zu schrauben?


    stonev:
    Kannst Du bitte mal den entsprechenden Auszug aus deiner doorpi.ini hier posten? Hab das Gefühl, daß damit was nicht ganz stimmt?!


    Bitteschön:


    /etc/modprobe.d/snd_bcm2835.conf ...


    Habe ich aufgrund des o. a. Post von Joker angelegt. Hatte es aber auch mit der blacklist.conf versucht. Das Ergebnis war bei mir in beiden Fällen gleich. Die USB Soundkarte wurde erkannt und war auch das einzige Sound Device - soweit gut. Der Sound-Test


    Code
    speaker-test -D hw:1 -c 2


    funktionierte. Die Konfiguration funktionierte also unter Jessie.


    Mit

    Code
    aplay -L


    wurde die USB Karte als Alsa Gerät angezeigt.


    der Alsamixer wurde komischerweise nicht mehr gefunden und gestartet. Und über den DoorPi kam auch kein Ton.

    Funzt irgendwie alls nicht, oder ich bin Nachtblind...


    Anbei mal der Log. ALSA: USB PnP Sound Device ist es schon mal nicht, aber ich finde auch nicht die Stelle, wo denn das stehen soll, was DoorPi selber erkennt.


    Könnte es damit zusammenhängen, dass der Alsamixer nicht mehr läuft? Wie könnte ich ihn manuell starten?

    Code
    pi@raspberrypi:~ $ sudo alsamixer
    cannot open mixer: No such file or directory


    Joker:
    Wenn das bei Dir funktioniert - könntest Du mir mal bitte Deine Ausgabe zu "amixer -c1 contents" posten?