Posts by PuMa

Nachtrag: Es hat sich ergeben, dass die Redaktion von Raspberry Pi Geek an dem Thema Interesse hatte. Der Artikel ist in der aktuellen Ausgabe erschienen: Videotelefonie-Artikel in Raspberry Pi Geek

Falls es dazu Fragen gibt, schicke ich die Beschreibung, Skripte etc. gerne auch per Email zu. Das ist dann nicht der Text des Artikels und nicht so hübsch im Layout, aber als Anleitung ausreichend.

So, Schluss. Auch dieser Versuch ist gescheitert,

Es gibt den Frame-Befehl zur Ausgabe des Tuner-Status, den man an den Fernseher schicken kann. Auf dem genutzten Sony Bravia Fernseher bleibt der Aufruf "Give Tuner Device Status" (echo 'tx 10:08:01' | cec-client -s -d 1) ohne Antwort, ebenso Abwandlungen und der Versuch, Parameter aus der DVB T2-Kanalliste des entsprechenden regionalen Senders für den Aufruf "Select Digital Service" zu erraten.

Was es auch gibt, ist eine Taste auf der Fernbedienung des Fernsehers, die "Digital/Analog" beschriftet ist und nicht nur auf den entsprechenden Tuner umschaltet, sondern auch gleich auf den TV-Eingang. Den zu drücken bekommt man glücklicherweise noch per Telefon erklärt.

Tja, der Versuch war gut, aber der Sony Bravia KDL-40RD455 lässt sich nicht im Netzwerk erreichen, weil er offensichtlich kein Smart-TV ist. Bleibt also nur CEC.
Ich versuche mal, den Status auszulesen und auszugeben und daraus dann abzulesen, welche Parameter die richtigen sind. Das müsste doch eigentlich möglich sein...

Hallo Micky,
Skripte für den Sony TV gibt es tatsächlich, danke für den Tip!
Ich schau mal, was ich davon gebrauchen kann. Aber da sollte die entsprechende Funktion dabei sein.

Okay, danke.

Ich schaue mal, ob es über LIRC oder die Dokumentation dazu was gibt, was mir weiterhilft.

Hallo,

gibt es wirklich niemanden, der sich mit der Steuerung des angeschlossenen Fernsehers mittels CEC beschäftigt hat? Oder ist meine Fragestellung nicht klar?

Wenn der Fernseher ausgeschaltet wird, bleibt dort der letzte Signaleingang ("Source") gespeichert. Das ist ggf. der HDMI des Raspi. Wenn dann der Raspi runter- und wieder hochfährt, kann er den Fernseher wieder an- und aktiv schalten, aber beim Runterfahren danach schaltet der Fernseher nicht auf Fernsehsender zurück, weil sein letzter aktiver Eingang eben der HDMI war. Ich versuche also, aktiv mit dem Herunterfahren auf den digitalen Empfang im Fernseher umzuschalten.

Ich denke, irgendetwas in die Richtung von echo 'tx 10:93:02:04:00:00:01:00:00' | cec-client -s -d 1 könnte mein Problem lösen. Was auf der Fernbedienung des Fernsehers einfach ist, weil man einfach die Signalquelle wählt, benötigt hier ganz viele Parameter - die ich nicht kenne.

Ich bin dankbar für jeden Tip!

Moin,

ich bin noch relativer Anfänger und bastele an einem seniorengerechten Videotelefoniesystem. Dabei habe nun ein sehr spezielles Problem.

Vorrede: Raspberry Pi 3 B+, aktuelles Buster-OS, HDMI an Sony Bravia KDL-40RD455 von 2017, Video über Jitsi im Chromium-Browser. Da sind alle Schwierigkeiten überwunden. Projektbeschreibung folgt in irgendeiner Form, sobald alles läuft.

Das Ziel ist, dass die Oma nur einen Taster auf dem Raspi-Gehäuse hat, der das System hochfährt und alles startet. Das funktioniert soweit. Der Taster wird von einem Python-Skript im Hintergrund überwacht und fährt das System auch wieder runter, wenn er erneut gedrückt wird. Das Skript soll den Fernseher auf den vorherigen Sender umschalten und den Raspi sicher runterfahren.

Ich nutze die CEC-Utils und habe mich von folgendem Artikel "beraten" lassen: Using cec-client on a Raspberry Pi

Beim Hochfahren schicke ich on 0 (umgesetzt als echo 'on 0' | cec-client -s -d 1), was den Fernseher ggf. aus dem Standby aufweckt.

Danach kommt unmittelbar as, um den Fernseher auf den HDMI-Port zu schalten, an dem der Raspi hängt.

Das funktioniert beides.

Beim Herunterfahren sollte eigentlich einfach is dem Fernseher mitteilen, das vom Raspi kein Signal mehr kommt. Nach meinem Verständnis sollt der Fernseher dann auf die vorherige Signalquelle zurückschalten. Das tut er nicht. Ein Workaround funktioniert allerdings: echo 'tx 10:9D:10:00' | cec-client -s -d 1 . Der macht genau das, was der erste Befehl tun sollte. Damit könnte ich fertig sein...

Oma schafft es aber, den Fernseher mit der Fernbedienung in Standby zu versetzen, während der Raspi noch läuft. Danach funktioniert das "inaktiv"-Setzen des Raspi-HDMI nicht mehr wie zuvor, weil der Fernseher "vergessen hat", was für eine Signalquelle er vor dem Raspi angezeigt hat. Inaktiv oder nicht, der HDMI-Eingang bleibt weiter aktiv. Nun ist sie völlig aufgeschmissen, weil sie am Fernseher die Signalquellen nicht ändern kann. Super-GAU: Der Fernseher bleibt schwarz!

Hier kommt also meine Quizfrage: Wie kann ich per CEC die Signalquelle am TV ändern und auf den Digitaleingang des TV schalten? Ich habe das Fernsehermodell angegeben, glaube aber, dass das Problem allgemeiner Natur ist und nicht speziell am Fernsehermodell liegt.

Probiert habe ich schon echo 'tx 1F:82:00:00' | cec-client -s -d 1 Das sollte im Prinzip dem CEC-Bus mitteilen, dass das aktive Signal der Fernseher ist. Es funktioniert nicht und ich vermute, dass es daran liegt, dass der Fernseher da nicht als eigene Signalquelle angesehen wird, da er mit einem analogen und einem digitalen Signal schon zwei eigene Quellen hat. Ich habe noch einiges mehr ausprobiert, aber das war ein wenig wahllos. Den (Fernseh-) Tuner auf einen speziellen Kanal umzuschalten funktioniert nicht, würde aber möglicherweise auch nicht die Signalquelle umschalten. Per scan sehe ich alle CEC-Geräte und weiß daher, dass ich beim Fernseher nicht mehrere Quellen habe.

CEC ist sehr speziell. Vielleicht hat sich schon jemand damit beschäftigt und kann mir einen Tip geben, der mich weiter bringt. Vielleicht denke ich falsch, wie CEC funktioniert?! Vielleicht weiß auch jemand, wo ich weiter forschen kann. Google war nicht so hilfreich...

Vielen Dank im Voraus!

PuMa

Moin,

ich setze ein Videotelefoniesystem auf dem RasPi für meine Mutter auf. Das Ziel ist, dass es nur einen Knopf gibt, mit dem alles hochgefahren wird und dann Jitsi in Chromium im Kiosk-Modus gestartet wird. In den Standardeinstellungen läuft Jitsi allerdings in HD, was meinen RasPi 3 B+ in die Knie zwingt und zu spürbaren Latenzen bei Bild und Ton führt.

Abhilfe schafft es, die Videoauflösung von HD herabzusetzen. Dann ist die Übertragung und die Wiedergabe flüssig. Allerdings wird meine Mutter nicht mit der Maus irgendwelche Einstellungen vornehmen. Daher ist m.E. die einzige Option, Jitsi entsprechende Parameter beim Aufruf mitzugeben. Wenn ich die finden würde...

Jitsi ist ja für einen Einsteiger nicht besonders verständlich dokumentiert, aber ich habe eine WhiteList gefunden, die nach meinem Verständnis Parameter enthält, die man beim Aufruf mitgeben kann. Welche davon entlasten die CPU deutlich, ohne die Videokonferenz zu sehr zu beschädigen? Oder gibt es noch eine andere Möglichkeit, z.B. Defaultparameter zu konfigurieren? Ich möchte meet.jit.si nutzen, also keinen eigenen Jitsi-Server aufsetzen.

In dem Zusammenhang habe ich auch noch eine andere Frage: Wenn der Raspberry Pi den Ton über den Fernseher ausgibt und über das Mikrofon der Webcam aufnimmt, führt das bei Jitsi zu Echos und "Quietschen" (Rückkopplungen). Jitsi empfiehlt zu dem Thema, ein Headset zu nutzen, bei dem die Tonausgabe natürlich direkt am Ohr und vom Mikrofon entkoppelt stattfindet - keine Option für meine Anwendung. Das Einfachste wäre m.E,, wenn man Jitsi dazu bringen würde, den vom eigenen Mikrofon stammenden Ton nicht mit auf der eigenen Sicht der Videokonferenz auszugeben. Gibt es dafür eine Option, die man einschalten kann?

Danke im Voraus für Ideen und Vorschläge!
PuMa

Hallo zusammen,

ich habe einen USB-Hub mit externer Stromversorgung und ein neues, besseres 3A-Netzteil getestet. Tatsächlich funktioniert beides, um das Krachen dauerhaft los zu werden. Der Ton hat noch eine spürbare Latenz (und das Videobild auch), aber die Technik steht schon mal. Die CPU-Auslastung liegt "nur" bei 70%. Trotzdem hilft gegen die Latenz, die Videoauflösung runter zu stellen - vielleicht hätte das auch schon gegen die Soundprobleme geholfen, weil das sicher auch den Stromverbrauch runter bringt.

Also das "Mysterium" hat wieder zugeschlagen.

Danke für die Unterstützung soweit!

Ich will das gesamte Projekt beschreiben, sobald es ein zufriedenstellendes Stadium erreicht hat. Ich weiß aber noch nicht, wo und wie. So oder so werde ich das ggf. hier verlinken, sollte ich erfolgreich sein.

Hallo schlizbäda,

Der Test von Soundkarte und Fernseher ergibt eine laute (hängt natürlich von der Lautstärke am Fernseher ab) und klare Übertragung. Ich habe auch die Soundkarte am Laptop getestet: geht. Aber dass die angeschlossenen Geräte nicht das Problem sind, ist inzwischen, glaube ich, ohnehin klar.

Ich habe also erst einmal die Themen abgearbeitet, die hier noch so genannt wurden.

Eine subjektiv deutliche Verbesserung hat det_lev_da mit seinem Hinweis bewirkt, die Reihenfolge des Startens der Prozesse zu prüfen. Ich habe das Python-Skript für den Shutdown, das ich oben schon mal angegeben hatte, jetzt aus der rc.local gestartet, was nach meinem Verständnis sicherstellt, dass es vor der grafischen Oberfläche läuft. In dem Skript wird die GPIO-Überwachung eingeschaltet. Das Krachen ist deutlich leiser - aber leider nicht weg. Danke für den Tipp!

Leider scheine ich doch ab und zu ein Spannungsproblem zu haben, dass dann immer wieder mal ein Krachen und Knirschen auslöst. Manchmal blitzt der Blitz kurz auf, manchmal kracht es auch ohne Blitz. Aber offensichtlich bin ich leistungsmäßig am Limit. Ich habe zwei Netzteile mit 3A ausprobiert, aber mit dem Netzteil am Raspi werde ich das nicht ganz weg bekommen. Webcam (obwohl besser als die zweite) und Soundkarte gemeinsam ziehen scheinbar bei Peakbelastung (also wenn wirklich beides zu übertragen ist) so viel Leistung, dass die Versorgung durch den Raspi nicht ausreicht. Die einzige mir einfallende Lösung dafür braucht Zeit: Ein USB-Hub mit separater Stromversorgung, Mal sehen, ob da Webcam und Soundkarte gemeinsam ran können. Ist aber eigentlich egal: Wenn die Webcam daran funktioniert, sollte der Saft vom Raspi für die Soundkarte ausreichen.

Blöd wäre, wenn es dann doch nicht daran liegt, sondern am Codec o.ä. Aber das Thema Codec in Jitsi ist mir derzeit noch zu hoch. Diese Bastelei ist damit erst einmal stillgelegt. Ich berichte, sobald ich die Stromversorgung stehen habe, ob das wirklich endgültig die Lösung war. Ich hoffe es! Danke auf jeden Fall soweit, insbesondere an Dich, schlizbäda.

Hallo schlizbäda,

danke dafür, dass Du Dich so ausführlich mit dem Problem beschäftigst. Es tut mir leid, wenn die Konfiguration immer noch nicht klar ist.

Das Mikrofon der Webcam kommt als 3,5mm Kinkenstecker aus dem Gerät und ist in den Mikrofoneingang der Soundkarte eingesteckt. Am Raspi sind die Webcam und die Soundkarte jeweils an USB eingesteckt. Die Webcam hat keine weitere externe Stromversorgung.

Außerdem gibt es das HDMI-Kabel zum Fernseher. Nur während der Bastelei ist auch noch eine Tastatur mit Touchpad angeschlossen, die später nicht da sein wird. Getestet habe ich alles mit und ohne die Tastatur.

Soundinput und -output habe ich im letzten Post schon beschrieben. Die Webcam wird vom Raspi erkannt und ohne Problem verwendet. Da die Kamera über Jitsi funktioniert, braucht die hier wohl nicht weiter betrachtet werden.

In der gegebene Konfiguration erscheint der Blitz NICHT. Ich gehe also erst einmal davon aus, dass die Stromversorgung ausreicht. Oder tritt das "Mysterium" auch auf, wenn der Raspi sich nicht beschwert? Ich hatte geschrieben, dass der Blitz auftrat, als ich die zweite Webcam getestet habe. Aber einen Einfluss auf das Krachen hatte das nicht. Also entweder ist zu wenig Leistung schon vorher das Problem (ohne Blitz) oder das Netzteil ist allgemein nicht für mein Soundproblem verantwortlich.

Ich konnte das Mikrofon mit der Soundkarte heute nur am Laptop testen. Da funzt es tadellos, kein Krachen oder Rauschen. Aber das Mikrofon hatte ich ja am Raspi auch schon getestet. An der Stelle, wo Urs-1956 hing, war ich da auch schon. Da der Raspi keinen Mikrofoneingang hat, kann er das Signal des Klinkensteckers ohne Soundkarte nicht verarbeiten. Mit Soundkarte wird durch den Raspi vom Mic zum Fernseher klarer Ton übertragen.

arecord --format=S16_LE --rate=16000 | aplay --format=S16_LE --rate=16000

Ich weiß allerdings nicht, ob das angegebene "Format" nicht letztlich einen Unterschied zu Jitsi macht, also das Analogsignal anders digitalisiert wird.

Morgen kann ich dann endlich am Raspberry weiter testen!

Quote from schlizbäda

Um hier Klarheit zu schaffen bevor wir weitermachen: Wie erfolgt die Audioausgabe ab dem RPi?

1) über dessen Klinkenbuchse

2) über HDMI zum Fernseher

3) über die USB-Soundkarte

4) über eine GPIO-Soundkarte über I2S (wie z.B. HifiBerry). Diese Variante fällt wohl weg.

5) sonstige analoge Verbindung mittels Klinken-/Cinchkabel zwischen RPi/RPi-Komponenten und Fernseher/Stereoanlage/Audioverstärker/PC-Boxen

Display More

Die Ausgabe erfolgt über HDMI an den Fernseher (bei Dir 2).

asound.conf sieht bei mir so aus:

pcm.!default {
        type asym
        capture.pcm "mic"
        playback.pcm "speaker"
}
pcm.mic {
        type plug
        slave {
                pcm "hw:Device"
        }
}
pcm.speaker {
        type plug
        slave {
                pcm "hw:b1"
        }
}

Hab ich mir natürlich auch nicht selbst ausgedacht, sondern gefunden bei Connect, Configure and Test USB Microphone and Speaker with Raspberry Pi

Das funktioniert im Test tadellos. Der Test ist: Jitsi-Meeting starten, Raspi auf stumm schalten (also Mic aus), Laptop mit Kamera und eingebautem Mic in dieselbe Jitsi-Konferenz und dann "Hallo! Hallo!" am Laptop. Latency ist spürbar, aber der Ton vom Fernseher ist klar und sauber.

Der Test andersherum: Am Laptop stumm, Mic am Raspi auf. Krachen und Knirschen auf dem Laptop, bevor das erste Wort gesprochen wurde. Tatsächlich wird aber auch "Hallo! Hallo!" übertragen, nur eben hinter lauten Nebengeräuschen. Jitsi beschwert sich übrigens: "Your Microphone seems to be noisy". Es liegt also am Signal vom Raspi.

Das Problem ist eindeutig irgendwo auf der Tonstrecke vom Mikrofon über die Soundkarte durch den Raspi zu Jitsi. Da der Sound direkt vom Mic and den Fernseher gut ist, sollten Mic und Soundkarte von der Hardware und technischen Funktion okay sein.

Kann es am Codec liegen, der zur Digitalisierung des analogen Signals verwendet wird?

Kann es tatsächlich an der Reihenfolge gestarteter Prozesse liegen?

Kann es am Netzteil des Raspi liegen? (Das einzige Hardware-Teil, dass ich noch nicht wirklich tauschen konnte, weil vorhandene Micro-USB Ladegeräte nur 2,1A schaffen. Damit läuft es zwar, aber mit dem "Blitz" in der Ecke, also zu wenig Leistung.)

Oder liegt es an etwas anderem?

Ich werde ab Donnerstag testen, was ich testen kann.

Tut mir leid, wenn ich nicht klar genug geschrieben habe, was ich einsetze. Die Hardware ist eine Webcam mit Mic, bei der das Mikrofon als Klinkenstecker über eine Soundkarte an den Raspi angeschlossen wird. Ich kann auch noch mal ein hochwertiges Mikrofon testen, aber da die Hardware funktioniert und ein Mic eigentlich ein einfaches Gerät ist, habe ich keine Hoffnung, dass die berichteten Soundprobleme damit verschwinden.

Mini HD 12MP Webcam Webkamera Mit Mikrofon USB LED Für Laptop PC Windows 10/XP

USB 2.0 zu 3.5mm Virtuell 7.1 Ch Kopfhörer 3D Externe Sound Karte Audio

Wie schon berichtet, habe ich auch eine andere Webcam mit Mic und eine andere Soundkarte probiert.

Es geht (mir) nicht um tolle Qualität, sondern erstmal darum, es hinzubekommen. Die Webcam ist übrigens erstaunlich gut. Wenn es dann läuft, kann ich die Komponenten einsetzen, die ein Ergebnis liefern, das alle glücklich macht.

Hallo zusammen,

vielen Dank für die vielen Rückfragen. Ich werde das einzeln nachprüfen, hatte gestern leider keine Zeit und vor Donnerstag wird es leider auch nix.

Was ich schon sagen kann, ist, dass die Soundkarte und das Mikro zusammen klaren Ton an den Fernseher übertragen, wenn ich den o.a. Code direkt starte. D.h. für mich, dass es eher kein Hardwareproblem ist. Das eingebaute Mic ist sicher nicht toll, aber wie geschrieben habe ich dasselbe Thema auch bei der zweiten Webcam mit eingebautem Mic. Wäre ja schon merkwürdig, wenn bei unterschiedlichen Marken und Modellen derselbe Hardwarefehler auftreten würde.

Also eher Software. Das Python-Programm hatte ich bisher nicht verdächtigt. Aber wenn die GPIO-Überwachung da eine Wechselwirkung haben kann?!

Mein Python-Skript sieht so aus:

# Shutdown-Skript für den Raspberry Pi
# Wartet auf LOW am Pin 5

import RPi.GPIO as GPIO
import os

GPIO.setmode(GPIO.BOARD)
# GPIO Pin 5 als Input mit Signal HIGH
GPIO.setup(5, GPIO.IN, pull_up_down=GPIO.PUD_UP)

try:
        while True:
                # Wartet darauf, dass der Pin mit GND verbunden wird
                GPIO.wait_for_edge(5, GPIO.FALLING)
                # 'is' deaktiviert den HDMI-Port am TV
                os.system("echo 'is' | cec-client -s -d 1")
                # Ordentliches Herunterfahren, auch von Chromium
                os.system("shutdown -h now")

except:
        GPIO.cleanup()

Das habe ich mir natürlich nicht selbst ausgedacht, Quelle ist [Tutorial] Ausschalter für den Raspberry Pi. Das Skript wird als .desktop-Prozess gestartet. Ist das vielleicht ein Problem? Es gibt ja verschiedene Wege, Prozesse bei Systemstart automatisch zu starten.

Falls ich da etwas probieren kann, würde mir ein Tipp sehr helfen! Danke im Voraus!

Ansonsten gebe ich in der zweiten Wochenhälfte ein Update, was ich noch versucht habe und was dabei heraus gekommen ist.

Moin,

ich bin noch relativer Raspberry-Anfänger, kann aber ein bisschen programmieren - und Internetsuche. Ich habe das Forum schon mal nach einer Lösung für mein Problem durchforscht, aber weder so ein Projekt noch eine Antwort auf meine konkrete Frage gefunden. Trotzdem vorab schon mal Respekt für das Engagement und die Geduld von vielen Experten hier!

Ich bastele an einer Oma-tauglichen Lösung für ein Videotelefoniesystem mit einem Raspberry 3 B+. Das Prinzip ist einfach und schon vor Jahren in einem Forum beschrieben worden: Video Calling on Raspberry Pi 3. Die beschriebene Lösung basiert auf dem Chromium-Browser und Jitsi als webbasiertem Videotelefonieprogramm. Allerdings scheint der Autor mit einer Bildübertragung zufrieden zu sein - dazu gleich mehr.

Hardware neben dem RasPi: Netzteil HN-5258 (5V, 2500 mA), Highspeed HDMI-Kabel, billige Webcam mit eingebautem Mikrofon, ein Taster und eine ganz einfache USB-Soundkarte.

Um es seniorentauglich zu machen, fehlt die Steuerung des Fernsehers über das HDMI-Kabel mittels CEC sowie ein Knopf zum Ein- und Ausschalten. Außerdem habe ich das Versenden einer Email an meine Emailadresse per msmtp integriert, um zu erfahren, wenn die Oma "online geht". An all diesen Themen habe ich mehr oder weniger lange herumgeforscht und -gebastelt. Mit Unterstützung des Suchmaschinenmonopolisten ließ sich das auch alles umsetzen. Ich habe letztlich ein eigenes Bash-Skript beim Starten ausführen lassen (.desktop) und darin dann alle Aktionen abarbeiten lassen. Der Ein-Ausschalter ist ein Taster, der bei Druck PIN 5 mit GND verbindet. Tasterdruck im Betrieb wird mit einem kleinen Python-Programm überwacht, das ggf. den Fernseher auf das vorherige Signal zurückschaltet und den RasPi sicher herunterfährt.

Jetzt stehe ich allerdings vor dem Problem, dass die Übertragung von Tönen nicht nur etwas versetzt ist - damit könnte ich leben - sondern dass der Ton vom Raspi auch sehr noisy ist. Es handelt sich dabei nicht um ein Rauschen, sondern um richtiges Krachen, das das eigentliche Tonsignal sehr laut überlagert. Versucht habe ich schon einiges. Ich habe alle Komponenten der Hardware getauscht. Eine andere (billige) Webcam führte dazu, dass der Raspberry sich über zu wenig Leistung aus dem Netzteil beschwerte, aber nicht zu besserem Ton. Eine andere Soundkarte änderte gar nichts. Und schließlich habe ich sogar einen anderen RasPi 3 B+ probiert, ohne Erfolg.

Mikrofon und Soundkarte arbeiten auch fehlerfrei zusammen, das habe ich getestet:

arecord --format=S16_LE --rate=16000 | aplay --format=S16_LE --rate=16000

Ich habe auch verschiedene Jitsi-Server probiert, um auszuschließen, dass es daran liegt. Man kann in Jitsi auch im Browser alle möglichen sprachverbessernde Prozesse ausschalten, die eigentlich den Ton verbessern sollen. Hat mich auch nicht weiter gebracht.

#config.p2p.enabled=false&config.disableAP=true&config.disableAEC=true&config.disableNS=true&config.disableAGC=true&config.disableHPF=true

Eine für Oma akzeptable Lösung wäre sicher, einfach das Bild zu übertragen und für den Ton zum Telefon zu greifen. Aber das macht mich nicht glücklich: Ich möchte eine runde Lösung!

Es gibt natürlich immer noch die Möglichkeit, dass ich als Einsteiger irgendetwas einfaches falsch mache. Das wäre mir echt sogar das Liebste! Aber jeden anderen Lösungsvorschlag nehme ich auch gerne auf.

Vielen Dank im Voraus für Eure Ideen!

PuMa